aria-conditional-attr
Web validation
ARIA states such as aria-checked, aria-expanded, or range values can confuse assistive technology when they appear on elements that already supply those semantics natively or when applied outside the widgets they belong to. Using these attributes only when the role and context demand them prevents contradictory information.
For example, an HTML input type="checkbox" or type="radio" already exposes its checked state, so adding aria-checked risks duplicating information (and is ignored by browsers that honor the native semantics). Likewise, hierarchy‑related attributes on a table row are meaningful only when the row sits inside a treegrid.
Pass Patterns
The native control already communicates its state
The native checkbox exposes its checked state, so no ARIA state is needed.
<label>
<input type="checkbox" checked />
I agree to receive updates
</label>Creating a custom widget and providing the correct role plus conditional attributes
A custom "select all" checkbox gets the checkbox role, so aria-checked is allowed. The mixed value tells users that only some of its options are checked.
<div role="checkbox"
tabindex="0"
aria-checked="mixed"
aria-controls="email-options">
Select all email notifications
</div>
<ul id="email-options">
<li><label><input type="checkbox" checked /> Product updates</label></li>
<li><label><input type="checkbox" /> Newsletter</label></li>
</ul>Fail Patterns
Adding an ARIA state that conflicts with the native state
aria-checked contradicts the native checked state, so assistive technology may receive conflicting information.
<input type="checkbox" checked aria-checked="false" />Using hierarchy attributes on a plain table row instead of a treegrid row
aria-level and aria-expanded are meaningful on a row only inside a treegrid.
<table>
...
<tr aria-level="1" aria-expanded="false">
<td>Downloads</td>
</tr>
</table>WCAG techniques
Sufficient techniques
Try It Yourself
Inspecting the browser dev-tools
- Inspect the element that failed validation.
- Verify its native HTML semantics and any explicit
role. - Cross‑check each ARIA attribute against the ARIA specification to confirm it is allowed for that role and whether any required condition (e.g., part of a composite widget) is met.
Expected results: Only ARIA attributes valid for the role and context are present.
Actual results: One or more invalid ARIA attributes are applied, such as aria-checked on a native checkbox or hierarchy attributes on an element that is not in a treegrid, indicating the failure.
FAQ
How does this issue relate to 4.1.2 Name, role, value?
Conditional ARIA attributes that violate their pre‑conditions add roles, states, or values the accessibility API does not expect. That breaks the "Name, Role, Value" promise and prevents assistive technology from presenting accurate information.
Why is this issue marked as Serious?
Conflicting or meaningless states can mislead people who rely on assistive technology, causing them to act on the wrong control or overlook critical information. While the page remains operable, the user experience is unreliable across major browsers and assistive technologies, justifying a Serious severity.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |