WCAG 2.2 · Guideline 4.1 · Robust
Compatible
Controls have to tell assistive technology what they are and what they are doing.
Your interface has two audiences. One is the person looking at it. The other is the software they brought with them, which reads a stripped-down version of your page called the accessibility tree and knows only what that tree exposes. This guideline is the contract between the two, and the contract runs both ways. Do not hide things from assistive technology, and do expose what you build in the standard way it already knows how to read.
Two success criteria live here and nothing sits above them. Guideline 4.1 has no Level AAA layer, and neither does the Robust principle it belongs to, which is the only one of the four principles you can say that about. There used to be a third rule, 4.1.1 Parsing, and it is the only success criterion ever removed from the standard. What is left is lopsided in a way worth knowing before you open a scan report. 4.1.2 Name, Role, Value carries fifteen automated test rules, more than any other criterion in WCAG, and ten of them name it as the thing they test. 4.1.3 Status Messages carries none. So one half of this guideline is the loudest thing in your report and the other half is silence. Neither half is guideline 4.1 itself, which is the goal both rules aim at.
- Rules
- 2
- Level A
- 1
- Level AA
- 1
- Human testing only
- 0
All 2 Compatible rules
- 4.1.2Level AName, Role, ValueEvery control has to tell assistive technology three things about itself.Partly scannable23 fixes
- 4.1.3Level AAStatus MessagesWhen a page tells you something without moving focus to it, that message has to reach assistive technology too.Partly scannable15 fixes
What goes wrong here
These are the failures we find repeatedly under 4.1, across sites of every size.
- A custom widget exposes no role, so assistive technology has nothing to call it and no idea how it is meant to work.
- ARIA is applied to elements that do not support it. Wrong ARIA is worse than none. It overrides something that was already correct.
- State is shown visually and never exposed. A control looks expanded, looks selected, looks pressed. It reports none of it.
- A status message appears with nothing exposing it as one. Not every change qualifies, so the question is whether this update tells the reader about progress, a result or an error without moving them.
- A toast appears and vanishes. Nothing had time to read it.
Who it affects
- Screen reader users, who receive what the markup exposes and nothing of what is merely drawn on screen.
- People using speech input and switch access, whose software reads much of the same exposed information, though what each product does with it differs.
- Anyone using a tool built on the page's semantics, including reader modes and translation, where a wrong role produces a wrong result.
How to work through it
- 1Inspect the computed accessibility information alongside the markup. The DOM tells you what you wrote and the computed exposure tells you what arrives.
- 2For each custom control, confirm it exposes a name, a role, its current state, and any value the user can set. Confirm too that a change to any of those is notified.
- 3Prefer the native element over the rebuilt one wherever one exists. It resolves most of this guideline before you start, and it does not resolve naming, so the control still needs a name that says what it does.
- 4Trigger every dynamic update and sort it first. Status messages need exposing without moving focus; a change that moves the reader is a different criterion and belongs to guideline 3.2.
- 5Test in the assistive technology combinations your audience actually uses. Verbose mode is a useful window and not a complete account of what any given product will do.
How the levels build
Two criteria live here and there is no AAA layer, which makes Robust the only principle with nothing at that level. Level A asks that every user interface component expose its name, its role, its state, its properties and its value, and notify assistive technology when any of them change. Level AA adds status messages, which arrived in WCAG 2.1 rather than at the start. WCAG 2.2 removed the parsing criterion outright, on the reasoning that assistive technology no longer parses HTML for itself, and the current WCAG 2.1 text goes further by deeming it always satisfied for content in HTML or XML. That matters when somebody hands you a scanner report full of markup validity errors. A missing role caused by bad nesting, or a wrong name caused by a duplicate id, is a real failure of another criterion and should be reported under that one instead. Where a jurisdiction has adopted an older version by date, its adopted text is what applies, and an editorial note in a later publication does not rewrite it.
Part of the Robust principle · browse by level: Level A · Level AA · or the full 55-rule library.
See how your site does against these rules.
An expert review plus a real blind screen-reader user, on up to 10 pages, every finding with its screenshot, criterion, and fix. $499, report in 5 business days.