See plans and pricing

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

  1. Find the element flagged in the report and identify which ARIA attribute has an invalid value.
  2. 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.
  3. 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.
  4. 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.
  5. 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>

View the full rule reference from Deque University

See plans and pricing