fix(aria-prohibited-attr): prohibit aria-label/labelledby on body and label - #5245
fix(aria-prohibited-attr): prohibit aria-label/labelledby on body and label#5245chutchins25 wants to merge 1 commit into
Conversation
… label The body and label elements prohibit an author-provided accessible name per ARIA in HTML, but slip through today because they resolve to a non-null role (body->document, label->chromium Label). Add an element-level elementsProhibitedAriaLabel option (body, label) that prohibits aria-label/aria-labelledby regardless of the exposed role. Closes #3410 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
straker
left a comment
There was a problem hiding this comment.
While this solves the problem I don't think it does so in the way we want. The true issue is that axe-core does not yet support the generic role. Both body and label should be implicit role of generic, which would then prohibit aria-label and aria-labelledby. So the fix to this issue should be to have generic be fully supported in axe-core.
|
Agree the root cause is the missing Options:
I lean toward (1) if #4747 is near-term. What's your preference? |
|
Option 1 is good |
Prohibits
aria-label/aria-labelledbyon thebodyandlabelelements, per ARIA in HTML "naming prohibited".What & why
Per ARIA in HTML:
body— role generic, Naming Prohibited.label— Naming Prohibited when exposed as generic / associated with a labelable element. The authoritative html-aria test fixture (tests/prohibit-names.html, authored by the spec editor) marks a bare<label aria-label>/<label aria-labelledby>as fail.Both currently pass
aria-prohibited-attrbecause they resolve to a non-null role (body→ implicitdocument;label→ chromiumLabel), so the check's "no role → prohibited" branch never runs.Fix
Adds a new
elementsProhibitedAriaLabelcheck option (default["body", "label"]) and an element-level short-circuit in the evaluate: elements in this list (and not overridden viaelementsAllowedAriaLabel) prohibitaria-label/aria-labelledbyregardless of the role they expose. These report as "no role" since the prohibition is tied to the element, not the implicit role.The
labelprohibition is unconditional (matches the html-aria test fixture and the issue), rather than attempting to detect labelable-element association.Note: the issue originally listed a third element (
rp), but the author struck it — not included.Behavior change
<body aria-label>/<label aria-label>(andaria-labelledby) now report onaria-prohibited-attr: a violation when the element has no visible text, or needs-review (incomplete) when it does. Element-level and gated onnodeName, so no other elements are affected.Tests
aria-prohibited-attrcheck unit — label single / plural / text-incomplete /elementsAllowedAriaLabelopt-out, plus an open Shadow DOM case.aria-prohibited-attrvirtual-rule —bodyandlabelviolations (bodycan't live in the shared integration page).aria-prohibited-attrintegration HTML/JSON —labelviolation + incomplete cases.doc/check-options.md— documents the newelementsProhibitedAriaLabeloption.Closes #3410