role-supports-aria-props
Configuration
Rule Details
Elements with ARIA roles must only use aria-* properties that the role supports. Many DOM elements carry an implicit ARIA role (e.g. <a href="#" /> → link, <input type="checkbox" /> → checkbox); elements with an explicit role attribute carry that role directly. The supported-properties table is sourced from aria-query's rolesMap.
The rule fires on a JSX opening element. It resolves the effective element name (through settings['jsx-a11y'].polymorphicPropName and settings['jsx-a11y'].components), looks up the explicit role attribute, and falls back to the implicit role table when no explicit role is set. It then walks every JSX attribute (excluding spreads and attributes whose value is null/undefined) and reports any aria-* attribute that is not in the role's supported-properties set.
Notable behavior locked in to mirror upstream:
- Membership against
rolesMapis case-sensitive —role="BUTTON"is silently not validated becausearia-query's keys are lowercase. - Mixed-case ARIA prop names (e.g.
aria-Checked) are silently not validated for the same reason. - Spread attributes are opaque, even when the spread argument is a literal object containing
aria-*keys. - Some elements have a context-sensitive implicit role:
<a>/<area>/<link>only acquirelinkwhen anhrefattribute is present;<img>loses itsimgrole whenalt=""or the literalsrccontains.svg;<input>/<menu>/<menuitem>/<select>depend ontype/multiple/sizevalues.
Examples of incorrect code for this rule:
Examples of correct code for this rule:
Rule Options
This rule takes no options.
Accessibility guidelines
Resources
- ARIA Spec — States and Properties
- ARIA Spec — Supported States and Properties
- Chrome Audit Rules, AX_ARIA_10
- aria-query —
rolesMap