- Success Criterion 4.1.2
- Conformance level A
Aria-Hidden Attribute Left on Content That’s Now Visible
4.1.2 — Name, Role, Value
Scenario
Setting
A ride-hailing app's trip booking screen
What’s wrong
aria-hidden (code hiding content from screen readers) left on revealed content, or applied to focusable controls (focusable-but-hidden ghosts).
Example
A ride-hailing app's trip booking screen is a good example: aria-hidden (code hiding content from screen readers) left on revealed content, or applied to focusable controls (focusable-but-hidden ghosts).
Why it matters
Screen-reader and voice-control users who can operate only what the accessibility tree exposes. On a ride-hailing app's trip booking screen, that means they can't complete the task without extra help.
How to test
Inspect aria-hidden="true" usage in DevTools: check it's never applied to revealed/visible content or to focusable elements — either case fails.
How to fix
Remove aria-hidden (code hiding content from screen readers) when content is revealed, and never leave focusable elements inside aria-hidden regions.
Outcome
With the fix in place on a ride-hailing app's trip booking screen, they get the same outcome as everyone else.
Who is affected
Screen-reader and voice-control users who can operate only what the accessibility tree exposes.
Learn more
- Understanding Understanding document (opens in a new tab)
Related scenarios
- Custom Dropdown or Slider With No Accessibility API Support
- Content Changes That Never Update Their Accessible Name
- Scripted Link or Button With No Real Role or Keyboard Support
- Clickable Div Turned Into a Control but Given No ARIA Role
- Form Field With No Programmatic Label at All
- Assistive Technology Never Told Which Element Currently Has Focus