ARIA attributes must be used as specified for the element's role

When ARIA attributes are applied to elements where the specification says they should not be used, the result is unpredictable behavior across browsers and assistive technologies. Different browsers handle these conflicts inconsistently — some ignore the ARIA attribute, others override the native state, and still others pass both values through. This inconsistency means that a screen reader user on one browser may hear a completely different state than a screen reader user on another, creating a confusing and unreliable experience.

This rule relates to WCAG 2.0/2.1/2.2 Success Criterion 4.1.2: Name, Role, Value (Level A), which requires that for all user interface components, the name, role, and states can be programmatically determined. When ARIA attributes conflict with native semantics or are used outside their allowed context, the programmatically determined state becomes ambiguous or incorrect. Users affected include people who are blind or deafblind and rely on screen readers, as well as people with mobility disabilities who use alternative input devices that depend on accurate ARIA information.

There are two main scenarios this rule checks:

The aria-checked Attribute on Native Checkboxes

The aria-checked attribute should not be used on an <input type="checkbox"> element. Native HTML checkboxes already communicate their checked state to the browser’s accessibility tree through the checked property. When you add aria-checked on top of this, you create two competing sources of truth. If the native checked state and the aria-checked value fall out of sync — which is easy to do — some assistive technologies will report the native state while others report the ARIA state. The user has no way to know which is correct.

How to fix it

You have two options:

1. Remove aria-checked and rely on the native checked attribute or property. If you need a “mixed” or indeterminate state, set the indeterminate property on the checkbox via JavaScript.
2. Replace the native checkbox with a custom element (e.g., a <div> or <span>) that uses role="checkbox" along with aria-checked. When doing this, you must also ensure the element is keyboard accessible (focusable and togglable with Space) and has an accessible name.

Row-Specific Attributes Outside a treegrid

The attributes aria-posinset, aria-setsize, aria-expanded, and aria-level are only valid on a row (a <tr> element or an element with role="row") when that row is inside a treegrid. These attributes describe hierarchical tree relationships — position within a set, nesting level, and expandability — which are concepts that only make sense in a tree grid context. When used inside a plain <table> or grid, these attributes serve no function and may cause screen readers to announce confusing or nonsensical information.

How to fix it

Either remove the unsupported attributes from the rows, or change the parent container’s role to treegrid if the data truly represents a hierarchical, expandable structure. If you switch to treegrid, make sure cells use role="gridcell" and that the keyboard interaction pattern matches what users expect from a tree grid (arrow key navigation for expanding/collapsing rows).

Examples

Bad example: aria-checked on a native checkbox

The aria-checked attribute conflicts with the native checkbox state.

<label>
  <input type="checkbox" aria-checked="true">
  I agree to make my website accessible
</label>

Good example: native checkbox without aria-checked

The browser communicates the checked state natively — no ARIA override needed.

<label>
  <input type="checkbox" checked>
  I agree to make my website accessible
</label>

Good example: custom checkbox using aria-checked

When building a custom checkbox, aria-checked is appropriate because there is no native checked state.

<div role="checkbox" aria-checked="true" tabindex="0" aria-label="I agree to make my website accessible">
  ✓ I agree to make my website accessible
</div>

Bad example: tree attributes on rows inside a plain table

The aria-level and aria-expanded attributes are not valid on rows inside a <table>.

<table>
  <tr aria-level="1" aria-expanded="false">
    <td>My Downloads</td>
  </tr>
  <tr aria-level="2">
    <td>Documents</td>
  </tr>
</table>

Good example: tree attributes on rows inside a treegrid

Changing the table’s role to treegrid makes these attributes valid and meaningful.

<table role="treegrid">
  <tr aria-level="1" aria-expanded="false">
    <td role="gridcell">My Downloads</td>
  </tr>
  <tr aria-level="2" class="hidden">
    <td role="gridcell">Documents</td>
  </tr>
</table>

Good example: removing unsupported attributes from a plain table

If the data is not hierarchical, simply remove the tree-related attributes.

<table>
  <tr>
    <td>My Downloads</td>
  </tr>
  <tr>
    <td>Documents</td>
  </tr>
</table>

Learn more:

Deque Reference

Deque University - How To Fix

→