Content has to remain parsable by the assistive technologies people actually use

What it is

A home-drawn switch clicks fine with a mouse, and “Notifications” sits beside it; a screen reader calls it an unnamed “clickable.” Switch to JAWS and Chrome, and even “clickable” goes quiet. Robust is not about whether a person can see or press. It is about whether the content can be parsed, by the browsers and assistive technologies in use, into a stable structure — name, role, state — that still lives across common pairings.

“We tested in current Chrome” is not robustness. Robustness is an interchange format: assistive technology does not read pixels; it reads the accessibility tree. If that tree collapses, the first three POUR principles can hold for eyes and still be empty for machines.

Why it happens

Assistive technology is another user agent. It consumes the accessibility tree, not the visual layout. Role sets the expectation of what the thing can do; name is how it is called; state is whether it is on or off. A custom control that only looks like a checkbox, but is a generic group in the tree, will not get the Space-to-toggle contract. Invalid markup, a page that is one big image, CSS content pretending to be a text node — all of these leave the tree incomplete or lying.

The second layer is diversity, not a single engine. People actually pair NVDA with Firefox, JAWS with Chrome, VoiceOver with Safari, TalkBack with the system browser — each pair with its own bugs and virtual-buffer behaviour. Robustness wants content to ride widely implemented semantics (HTML controls, proven ARIA patterns), not a private behaviour of one pairing. POUR puts this last because perception, operation, and understanding can all pass in a “sighted, mouse, one browser” test while the tree is still empty.

Studying it

Open the accessibility tree or equivalent inspector and, for each interactive control, see whether Name, Role, and Value/State are all present. Then run the same task on real pairings: NVDA+Firefox, JAWS+Chrome, VoiceOver+Safari; add TalkBack on mobile. A step that works in one pair and goes mute in another is a robustness failure, not “the user does not know the reader.”

Independent variables: markup strategy (native control / legal ARIA / canvas-only / invalid nesting), browser–AT pairing. Dependent variables: whether name, role, and state coexist in the tree; in how many pairings the task completes; how many steps succeed in only one pairing.

Automation can catch missing roles and broken ARIA references. It cannot catch a live region swallowed by one pair’s virtual buffer. A compatibility matrix is not optional; a pass in one pair is not a pass in all.

Where it stops holding

Brand-new interaction that no AT yet maps (some WebXR widgets, a custom canvas editor) may have nothing parsable for a while; robustness then recedes to an AT-usable alternative view, not a pretence that the 3-D scene is already in the tree. A third-party embed that is fully out of hand can break page-level robustness inside one iframe — the failure sits in the decision to embed, not in “our own buttons are native.” Browser and AT updates will break yesterday’s robust content; robustness is a continuing property, not a medal from one build. A static native-HTML document with no script is almost automatically robust; it does not need ARIA piled on for the sake of it.

Applying it

• Prefer native controls to drawings. If you draw, fill in name, role, and state on a known pattern, and write state changes back to the tree, not only to appearance.
• Do not let CSS-generated pseudo-text be the only name source; the tree needs a real node.
• How to check: every interactive item in the inspector has Name, Role, and State; then walk the critical path with NVDA+Firefox, JAWS+Chrome, and VoiceOver+Safari. Treat a step that lives in only one pairing as unparsed, not as “an individual environment issue.”

Related

• Same group: J1.01.1 Information must still be gettable when a sensory channel is missing · J1.01.2 Every function must be triggerable from an input method the person can use · J1.01.3 Presentation is not the same as being able to understand the information and the action
• Nearby: J5.02 Accessibility tree and roles · J5.07 Compatibility testing · J5.08 Limits of automated checking
• Search terms: robust · POUR · accessibility tree