WCAG 2.0 · Level A · Robust
4.1.2 Name, Role, Value
Manual verification
How to validate 4.1.2 by hand
Inspect custom user-interface components and verify that assistive technology receives their name, role, value, and state changes.
Start with the extension result
Reopen the reported URL and reproduce the same state (for example, after expanding a menu or submitting a form). Use the result’s Highlight action when available, or its affected-element details and CSS selector, to find the reported content. Apply the checks below to that content and its context. If the element or state has changed, rescan and record that difference before deciding whether the finding still applies.
- Navigate to each custom control with a screen reader or inspect it in the accessibility tree.
- Check that its accessible name identifies it, its role communicates its type, and its current value/state is accurate.
- Operate the control and verify changes such as expanded, selected, checked, disabled, or value are announced and can be set.
Evidence to record
Record the control, expected name/role/value/state, actual exposed values, and the action that causes an incorrect or missing update.
Scope and exceptions
Native HTML controls generally supply these semantics when used correctly. This criterion targets user-interface components and their programmatic information; status announcements are covered separately by 4.1.3.
Record the review outcome
- Confirmed: the recorded evidence shows the requirement is not met in the tested page state, and no applicable exception explains it.
- Not reproduced: the reported issue is absent in the current state. Record the URL, state, and affected element you checked; this does not prove other pages or states conform.
- Needs more review: evidence is incomplete, the content requires human judgment, or an exception is uncertain. Record what remains to be checked instead of treating it as a pass.