aria-valid-attr
Web validation
Every attribute that begins with aria- has a specific spelling defined in WAI-ARIA. When you invent, mistype, or use an outdated attribute, assistive technology simply ignores it, so users never benefit from the information you meant to convey. Always choose attributes from the current ARIA specification and copy them exactly.
Pass Patterns
A recognized ARIA attribute
An element uses a recognized ARIA attribute.
<button aria-expanded="false" aria-controls="main-menu">Menu</button>A correctly spelled ARIA attribute
The attribute belongs to ARIA and uses the correct spelling.
<div role="tablist">
<div role="tab" aria-selected="false">Reviews</div>
</div>Fail Patterns
The attribute name contains a misspelling
The code misspells the aria-activedescendant attribute.
<input type="text" role="combobox" aria-activedescendent="el-1" />An element uses a fabricated ARIA attribute
There is no aria-visible attribute in the ARIA specification.
<button aria-visible="true">Close</button>Try It Yourself
Using a screen reader
New to screen reader testing, or need a refresher?
Review this article first: Practical guides for using screen readers
- Turn on a screen reader.
- Navigate to the component containing the ARIA attributes.
- Listen for the information communicated, such as state or description.
Expected results: The screen reader conveys the role and state you intended.
Actual results: If the attribute name is invalid, the announced information is missing or incomplete.
Inspecting the browser dev-tools
- Open the page in a modern browser.
- Select the element in the Elements pane.
- Open the Accessibility or ARIA panel.
- Check that every
aria-*attribute appears by name.
Expected results: All attributes listed in the dev-tools panel match their spelling in the markup.
Actual results: If an attribute is invalid, it does not appear, signaling that assistive technology will also ignore it.
FAQ
How does this issue relate to 4.1.2 Name, role, value?
SC 4.1.2 requires that user-interface components expose accurate names, roles, and states to assistive technology. Using a valid ARIA attribute name is essential to fulfill that requirement. An unrecognized name prevents the state or property from being exposed.
Why is this issue marked as Critical?
Invalid ARIA attribute names silently break the communication channel between your code and assistive technology. Users who rely on that information, such as people who are blind or who use voice control, cannot perceive component states or relationships, making the interface unusable.
Where can I find a list of all valid ARIA attributes?
Section 6.6 of the ARIA specification (Taxonomy of WAI-ARIA States and Properties) lists all ARIA attributes categorized by their purpose.
- Widget Attributes: Contains attributes specific to common user interface elements that support the ARIA widget roles and native HTML elements.
- Live Region Attributes: Contains attributes that indicate content changes might occur without the element having focus, like status messages and alerts.
- Drag-and-Drop Attributes: Lists attributes that indicate information about drag-and-drop interface elements.
- Relationship Attributes: Lists attributes that indicate relationships or associations between elements that cannot be readily determined from the document structure.
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. |