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

<div class="checkbox" onclick="toggle()"></div>

Why it matters

Screen-reader and voice-control users who can operate only what the accessibility tree exposes.

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.

<input type="checkbox" id="opt-1">

<label for="opt-1">Email notifications</label>

A native input exposes its role and checked state automatically; a styled div exposes none of that without a lot of manual ARIA.

Outcome

On a ride-hailing app's trip booking screen, this barrier is gone for screen-reader and voice-control users who can operate only what the accessibility tree exposes — they reach the same outcome without extra effort.

Who is affected