What This Rule Checks
ARIA attributes provide essential information for assistive technologies, but certain attributes are prohibited for specific roles. Using these prohibited attributes may lead to important information being ignored by screen readers, which can result in an inconsistent or confusing user experience.
Who Is Affected
This issue primarily affects: Blind users, who rely entirely on screen readers or braille displays to navigate and interact with content; Deafblind users, who rely on braille displays and cannot access visual or auditory content; Mobility users, who navigate using keyboards, switches, voice control, or other assistive input devices.
Why This Matters
Prohibited ARIA attributes are ignored by assistive technologies per spec, so the intended semantic enhancement simply doesn’t work. Developers may believe the element is accessible when it’s actually not, creating a false sense of compliance.
How to Fix
To ensure accessibility, avoid using ARIA attributes that are prohibited or redundant with native HTML elements. These attributes can interfere with the element’s default behavior and confuse assistive technologies.
Examples of common issues to avoid include:
- Avoid applying aria-checked to native checkbox elements, as the browser manages the checkbox state automatically.
- Avoid applying aria-hidden=”true” to focusable elements, as it makes them both hidden and focusable, causing confusion.
- Avoid using aria-disabled on elements where native disabled functionality already exists, such as form controls.
- Avoid applying aria-label to non-interactive elements like <div> or <span>, unless these elements are given a role that makes them interactive, such as role=”button”.
- Avoid using aria-haspopup on elements that do not trigger a popup, such as a modal or dropdown menu.
- Avoid using aria-pressed on elements that aren’t toggleable buttons, as this attribute indicates the pressed state of a button.
- Avoid applying aria-expanded to non-collapsible elements, such as static text or images.
- Avoid applying aria-live to static content, as this attribute is meant for dynamic content that updates without a page reload, such as notifications or live feeds
Code Examples
<!-- aria-label on a generic div with no role -->
<div aria-label="Important section">
<p>Content here</p>
</div>
Copy
<!-- aria-label on element with an appropriate role -->
<div role="region" aria-label="Important section">
<p>Content here</p>
</div>
<!-- Or use a native landmark -->
<section aria-label="Important section">
<p>Content here</p>
</section>
Copy
Common Mistakes to Avoid
- Adding aria-label to elements that don’t support naming (generic div, span, p).
- Assuming any element can receive any ARIA attribute.
- Not checking the WAI-ARIA spec for which attributes are prohibited per role.
Tip: Remember the first rule of ARIA: don’t use ARIA if a native HTML element can provide the same semantics. Native elements come with built-in keyboard handling and screen reader support that ARIA cannot replicate.
Related WCAG Criteria
- 4.1.2: Name, Role, Value