ACT Rules Consistency Alignment
Track and resolve gaps between the Equal Access Checker's current ACT rule coverage and the W3C ACT Implementations listing.
Findings are based on the act-report-v2.txt from build 4.0.31.
Supersedes #1463.
❌ Not implemented — no checker rule mapped
🔴 Wrong results on specific test cases
Rules with an ACT mapping that produce incorrect outcomes on some test cases:
🟡 Applicability scope mismatch — returning inapplicable instead of failed
Rules where the checker's applicability condition is too narrow, causing failures to be reported as inapplicable:
🟠 can't tell results — potential-only reporting
| ACT Rule |
WCAG SC |
Detail |
| bc659a — Meta element has no refresh delay |
2.2.1 |
5 cases (1 pass + 4 fail) return can't tell. These are redirect cases the engine marks as potential rather than definitive. The mapping in meta_refresh_delay.ts intentionally excluded bisz58 (the no-exception variant). Needs review to determine whether promoting these to definitive aligns with IBM guidance. |
✅ Passes all approved test cases — currently listed as "Partially consistent"
The W3C listing shows these as "Partially consistent" despite no wrong results in the report. The discrepancy is likely a WCAG SC checkpoint mapping disagreement rather than a logic error. Each needs a review of the W3C implementation page to identify the specific mapping difference and confirm alignment with IBM guidance.
Process
Each row above should become a child issue in this Epic. Before making any change, confirm that the proposed alignment agrees with IBM accessibility guidance policy.
ACT Rules Consistency Alignment
Track and resolve gaps between the Equal Access Checker's current ACT rule coverage and the W3C ACT Implementations listing.
Findings are based on the act-report-v2.txt from build 4.0.31.
Supersedes #1463.
❌ Not implemented — no checker rule mapped
heading_content_existscovering this scenario butact: []— no mapping. Needs investigation to confirm alignment and add mapping.🔴 Wrong results on specific test cases
Rules with an ACT mapping that produce incorrect outcomes on some test cases:
autocompleteattribute has valid valueearl:failed(false positive)failed; Failed Example 4 →inapplicable; Inapplicable Examples 1 & 3 →failedearl:failed(false positive). A TODO comment inaria_hidden_nontabbable.tsnotes "Handle testcase with focus jumping away".🟡 Applicability scope mismatch — returning
inapplicableinstead offailedRules where the checker's applicability condition is too narrow, causing failures to be reported as inapplicable:
inapplicableinapplicableinapplicablefailed(false positive)🟠
can't tellresults — potential-only reportingcan't tell. These are redirect cases the engine marks aspotentialrather than definitive. The mapping inmeta_refresh_delay.tsintentionally excludedbisz58(the no-exception variant). Needs review to determine whether promoting these to definitive aligns with IBM guidance.✅ Passes all approved test cases — currently listed as "Partially consistent"
The W3C listing shows these as "Partially consistent" despite no wrong results in the report. The discrepancy is likely a WCAG SC checkpoint mapping disagreement rather than a logic error. Each needs a review of the W3C implementation page to identify the specific mapping difference and confirm alignment with IBM guidance.
Process
Each row above should become a child issue in this Epic. Before making any change, confirm that the proposed alignment agrees with IBM accessibility guidance policy.