WCAG 2.2 · Principle 4 of 4

Robust

Does your code tell assistive technology what everything is and what it is doing?

Robust is the smallest principle in WCAG by a long way. One guideline, two rules, and no Level AAA layer at all, which is true of none of the other three. It is also the one people underrate, because a count of two reads like an afterthought. Every custom dropdown, dialog, tab set and toggle on a modern site lives or dies on 4.1.2 Name, Role, Value, and a site built out of components is mostly custom controls.

Both rules here are inside every audit, 4.1.2 at Level A and 4.1.3 Status Messages at Level AA. Tooling reaches them in opposite directions, which is worth knowing before you open a scan report. W3C files fifteen automated test rules under 4.1.2, more than against any other criterion in the standard, and ten of those name it as the thing they test. Seven of the ten check only that a name exists rather than whether the name says anything. Against 4.1.3 it publishes none. A scanner can see the markup that would carry a status message, and it cannot tell you whether anything was ever announced, so you have to make the thing happen and listen. And Robust is the principle, not the test. Those two numbered rules are the test.

Rules: 2
Level A: 1
Level AA: 1
Human testing only: 0

All 2 Robust rules, by guideline

4.1 Compatible· Controls have to tell assistive technology what they are and what they are doing.

What Robust actually covers

Whether software other than a browser can work out what your page is. That software reads the accessibility tree, which is the stripped-down version the browser builds and hands over, and it knows only what the tree exposes.

The duty runs both ways and people usually carry one half of it. Do not hide things from assistive technology, which is what aria-hidden on a focusable element does. And do expose what you build in the standard way it already knows how to read.

One guideline and two criteria, and both of them are inside every audit. There used to be a third rule here, 4.1.1 Parsing, and it is the only success criterion the standard has ever removed. Assistive technology stopped parsing HTML for itself, so it now reads the tree the browser has already built and the rule had nothing left to protect.

What fails most here

A custom control that declares no name, no role, or no current state to the accessibility tree.

Every dropdown, dialog, toggle and tab set built out of div elements has to say in code what it is and what it is doing. Most of them say part of it. The result is a control announced as button and nothing else, with no indication of what it controls or whether it is currently open.

Who notices first

Screen reader users, who receive what the accessibility tree exposes and nothing of what is merely drawn on screen.
People using speech input, who activate a control by saying its name, so a control with no name has no name to say.
People using switch access, who depend on focus moving through controls that declare themselves as controls.
Anybody who has pressed Add to cart twice, because nothing told them the first press worked.

The common misreading

“Two rules means Robust matters least.”

Two rules is not two problems. 4.1.2 Name, Role, Value applies to every custom control on the page, and on a site built out of components almost everything is a custom control. Our audits trace complaints like could not select a size straight back to it, over and over. The fix is usually small, which is the good news. Use the native element and the tree fills itself in.

The other three principles

Or browse by conformance 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.

Order your audit