About this AccessLint rule
Certain ARIA roles prohibit specific ARIA attributes. When a prohibited attribute is used on an element with one of these roles, browsers and assistive technologies may ignore the attribute entirely, or worse, the attribute may produce unpredictable behavior. This rule flags cases where an ARIA attribute appears on an element whose role does not allow it.
The most common example involves the aria-label and aria-labelledby attributes. These attributes provide an accessible name for an element, but some roles explicitly do not support naming. Roles like none, presentation, and generic exist to remove or neutralize semantics, so giving them a name contradicts their purpose. Text-level semantics roles such as code, emphasis, strong, deletion, insertion, subscript, and superscript also prohibit naming attributes because their meaning comes from the text content itself, not from a label.
Screen reader users are the most affected by this issue. When a prohibited attribute is present, a screen reader might ignore it silently, leaving the user without the information the author intended to convey. In other cases, the screen reader might announce unexpected or confusing output. Either way, the result is an unreliable experience.
This rule maps to WCAG 2.1 Success Criterion 4.1.2 (Name, Role, Value) at Level A. That criterion requires that user interface components have proper names and roles that assistive technologies can determine programmatically. Using a prohibited attribute means the accessible name cannot be reliably determined, which violates this criterion.
How to fix it
- Identify the element's role, whether it is set explicitly via the
roleattribute or implicitly through the HTML element itself (for example, a<span>has the implicit rolegeneric). - Check whether the flagged ARIA attribute is allowed for that role. The WAI-ARIA specification lists prohibited attributes for each role.
- Remove the prohibited attribute, or change the element's role to one that supports the attribute.
If the goal is to label an element that has a role like generic or presentation, consider whether a different element or role would be more appropriate. For instance, if an element needs an accessible name, it likely should not have role="presentation" or role="none" in the first place.
Examples
Prohibited aria-label on a generic element
A <span> has the implicit role generic, which prohibits aria-label:
<span aria-label="Status indicator">Active</span>
The aria-label is prohibited here and may be ignored by assistive technologies. To fix this, either remove the attribute and rely on the text content, or use an element or role that supports naming:
<!-- Option 1: Remove the prohibited attribute -->
<span>Active</span>
<!-- Option 2: Use a role that supports aria-label -->
<span role="status" aria-label="Status indicator">Active</span>
Prohibited aria-labelledby on a presentation role
An element with role="presentation" is meant to have its semantics removed. Adding aria-labelledby contradicts that intent:
<table role="presentation" aria-labelledby="table-title">
<tr>
<td>Layout content</td>
</tr>
</table>
If the table is purely for layout and should have no semantics, remove the labeling attribute:
<table role="presentation">
<tr>
<td>Layout content</td>
</tr>
</table>
If the table has meaningful data and needs a label, remove role="presentation" instead:
<table aria-labelledby="table-title">
<caption id="table-title">Quarterly results</caption>
<tr>
<td>Layout content</td>
</tr>
</table>
Prohibited aria-label on a text-level semantics role
The <code> element has the implicit role code, which does not support naming:
<code aria-label="Variable name">myVar</code>
Remove the prohibited attribute. The text content of the <code> element is already available to assistive technologies:
<code>myVar</code>
If surrounding context is needed, add it as visible text rather than through a prohibited attribute:
The variable <code>myVar</code> stores the user's name.
Detect accessibility issues automatically
Rocket Validator scans your site with complementary accessibility engines, helping teams find issues across every page.
Help us improve our guides
Was this guide helpful?
๐
Trusted by teams worldwide
Validate at scale.
Ship accessible websites, faster.
Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.
Scheduled Reports
API Access
Open Source Standards
$7
/ 7 days
Pro Trial
Full Pro access. Cancel anytime.
Start Pro Trial โ
Join teams across 40+ countries