aria-valid-attr-value
Web validation
ARIA states and properties give assistive technologies the information they need to present interactive components accurately. When you supply a value the specification does not recognize such as a misspelling or a token that is out-of-range, the browser drops the attribute. As a result, assistive technology users may receive the wrong name, state, or instructions, or none at all. Used correctly, ARIA enriches accessibility. Used incorrectly, it silently removes it.
Pass Patterns
Valid boolean value
The aria-hidden attribute marks the element as hidden.
<!-- aria-hidden accepts only "true" or "false" -->
<div aria-hidden="true">
<!-- Decorative content -->
</div>Valid tristate value
The mixed token communicates an indeterminate state that assistive technologies can announce.
<!-- "mixed" is an allowed value for aria-checked on a checkbox -->
<div role="checkbox" tabindex="0" aria-checked="mixed">Subscribe to newsletter</div>Fail Patterns
Undefined value
Because visible is not a valid boolean token, the browser ignores the attribute.
<!-- "visible" is not allowed for aria-hidden -->
<div aria-hidden="visible">
<!-- Decorative content -->
</div>Misspelled value
A single typo makes the value invalid, leaving the component’s state unavailable to assistive technology.
<!-- "tru" is not a valid token -->
<div role="checkbox" tabindex="0" aria-checked="tru">Subscribe to newsletter</div>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
- Load the page and open a screen reader.
- Navigate to the element with the ARIA attribute.
- Listen for the state or property the attribute sets.
Expected results: The screen reader conveys the intended state (for example, “checked” or “mixed”), or skips an element hidden with aria-hidden="true".
Actual results: The state is missing, or the element is announced as if the attribute were absent (for example, a “hidden” element is read aloud).
Inspecting the browser dev-tools
- Open DevTools, select the element, and view the Accessibility pane.
- Check that each
aria-*attribute appears in the computed properties with its value.
Expected results: The attribute appears with a valid value.
Actual results: The property is absent, confirming the browser discarded the invalid value.
FAQ
How does this issue relate to 4.1.2 Name, role, value?
SC 4.1.2 requires that every component expose a programmatically determinable name, role, and all relevant states and properties. Invalid ARIA values break this link because assistive technologies cannot read or update the component’s state.
Why is this issue marked as Critical?
When values are invalid, assistive technologies receive no usable state information. Users who rely on this information, such as people who are blind, Deaf-blind, or who have limited mobility, cannot understand or operate the component.
Where can I find a list of all valid ARIA attribute values?
Section 6.6 of the ARIA specification (Taxonomy of WAI-ARIA States and Properties) lists all ARIA attributes categorized by their purpose.
Clicking an attribute name on the list will take you to the attribute definition, where you can find the attribute's valid values table. For example, refer to the definition for the aria-checked attribute.
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. |