ARIA attributes must conform to valid values
Estimated effort: about 10 minutes.
Many ARIA attributes only accept a specific, limited set of values — for example aria-expanded must be exactly "true" or "false", and aria-hidden must be "true" or "false", never anything else. A misspelled or made-up value (like aria-expanded="1" or aria-hidden="yes") is silently ignored by assistive technology, so the intended state is never actually communicated.
How to fix it
- Find the element flagged in the report and identify which ARIA attribute has an invalid value.
- Check the correct allowed values for that specific attribute — most true/false attributes (aria-expanded, aria-hidden, aria-disabled, aria-pressed's boolean form) only accept the literal strings "true" or "false", not "1"/"0", "yes"/"no", or boolean-looking values without quotes.
- A common e-commerce example is a mobile filter/accordion toggle or "show more reviews" button whose aria-expanded value is generated by application code as a number (0/1) or a non-string boolean instead of the exact string "true"/"false" — fix the code that outputs the attribute so it always writes the literal strings.
- Also check ID-reference attributes like aria-labelledby or aria-controls: the value must exactly match the id of an element that actually exists in the same document; a typo'd or stale id reference is also an invalid value.
- Re-check with the browser's Accessibility Inspector or DevTools Elements panel that each ARIA attribute's value matches its documented allowed values exactly.
Before and after
Before
<button aria-expanded="1" aria-controls="filters-panel">Filter products</button>
After
<button aria-expanded="true" aria-controls="filters-panel">Filter products</button>