Glossary · Accessibility term

Robust

Robust is the fourth of WCAG's four principles, and it asks that content be built well enough for a wide variety of user agents, including assistive technology, to interpret it. Interpret, not render. A page can paint perfectly and still tell a screen reader nothing about what any of it is. It is the smallest principle in the standard by a distance, one guideline and two live rules against Operable's thirty-four, and it is the only one that adds nothing at all at Level AAA. It is also where hand-built controls fail hardest, because those two rules ask for exactly the things a div forgets. A name, a role and a value, and an announcement when a status changes.

In practice

The whole principle is two rules, and knowing both is knowing the principle. Every control has to expose its name and its role, and anything a user can set has to be settable by software too, with any change made available to user agents and the assistive technology working through them. That rule is Level A, and note the direction. It is not that every value must be user-editable. It is that whatever the user can already change, software must be able to change and read as well. Then status messages have to be available to a screen reader without focus moving to them, at Level AA, and the phrase to hold on to there is without taking focus. That is what separates a quiet "3 results" from an error you tab to.

It used to be three. Parsing was removed in WCAG 2.2, on the stated grounds that assistive technology no longer parses HTML itself, so the problems it addressed either went away or belong to other rules now. The current 2.0 and 2.1 texts carry a note treating it as always satisfied for content using HTML or XML, so a checklist that still lists it is not out of date and an HTML page should not be failed on it. Scanners keep reporting duplicate IDs anyway, and duplicate IDs are still a real defect, because a label reference and a form association both resolve by ID. Report that under the rule it actually breaks.

Robust bottoms out in other specifications, which is why a role-related finding cannot cite WCAG alone. WCAG says a name and a role must be programmatically determinable and deliberately never says which roles exist or how a browser computes a name. ARIA and the naming specification answer that. There is a condition on top of that. A pattern that is correct by the specification but that nothing on the market implements does not satisfy the rule, because accessibility support is part of the test rather than a formality.

Why it matters

Robust failures do not degrade gracefully. A contrast failure makes something hard to read. A missing name leaves the control there and unidentified, so a reader hears button and has to guess or press it and find out, which on a page with a delete button is a bet rather than a nuisance. The volume is the other half. On the top million home pages in February 2026, nearly half carried an empty link and three in ten carried an empty button, and a third of all form inputs had no accessible name by any route at all. That is one criterion turning up on most of the web.

The one planning fact worth having

Robust is the only principle in WCAG with no Level AAA criteria at all. So a team aiming at AAA has nothing extra to do here, while every other principle adds obligations. That also cuts the other way. There is no higher bar to climb toward, which means whatever you fail under Robust, you fail at Level A or AA, where the laws are.

Where this shows up on the site

Related terms

Knowing the word is the easy part.

Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.

Run the free scan