Robust (In Depth)

Robust is the fourth POUR principle, and in some ways it's the most abstract. The core idea is that content should work reliably across the browsers and assistive technologies that exist now, and keep working as those tools evolve. You're not just building for one environment. You're building for a range of tools you don't control, interpreting your HTML in ways you can't always predict.

The practical upshot is narrower than it sounds. Robustness mostly comes down to writing valid, standards-compliant HTML and ARIA labels. Browsers and assistive technologies are built to interpret proper HTML. The closer yours is to spec, the less likely something breaks in an unexpected way.

A note on scope: this page covers the criteria most relevant to building a typical website. A handful of niche and AAA-only criteria aren't covered here — not because they don't matter, but because they apply to narrower situations or represent an aspirational bar rather than a baseline. If you want the full picture, W3C's Understanding WCAG 2.2 — Robust has every criterion with context and examples.

But first, ARIA

ARIA (Accessible Rich Internet Applications) gets mentioned a lot in this section. It's a set of attributes that let you add semantic meaning to HTML elements that don't have it natively — roles, states, properties, live region behavior.

Used well, ARIA fills gaps where HTML semantics aren't enough. Custom widgets, single-page app dynamic content, and interactive components like autocomplete menus often genuinely need it.

Used carelessly, ARIA creates more problems than it solves. The first rule of ARIA is essentially: don't use ARIA if a native HTML element does the same job. A <button> beats a <div role="button"> in every way. It's keyboard-operable by default, it has the right role, and it fires the right events. Adding ARIA to a div gets you the role announcement; it doesn't get you keyboard interaction or focus behavior. You have to build those separately. Unless you know how to ensure those things, it can get very complicated fast.

The second thing worth knowing: ARIA can override native semantics in ways that break things. role="presentation" on a table removes its table semantics. aria-hidden="true" hides an element from assistive technology entirely, which is sometimes the correct move and sometimes a disaster. ARIA trusts you to use it correctly, which means it has no defenses for incorrect use.

For most static sites, you can go a long way without touching ARIA. Write semantic HTML, use native form elements, label everything properly, and the Robust requirements largely take care of themselves. If you want to get into ARIA, take a look at the links in the "Going Deeper" section below.

Guideline 4.1 — Compatible

Content needs to be compatible with current and future user agents, including assistive technologies. This guideline used to have three success criteria; as of WCAG 2.2, it has two.

Parsing (4.1.1) — Obsolete in WCAG 2.2

WCAG 2.2 removed this criterion from compliance requirements. It used to require that HTML be well-formed enough that browsers could parse it without errors. That made sense when browser parsing was inconsistent. Now that browser parsing is standardized, those guarantees are built in regardless of HTML validity, and the criterion was removed as formally redundant.^[1]

That doesn't mean invalid HTML is fine. Writing valid HTML is still good practice — it just doesn't carry a compliance requirement under WCAG 2.2 anymore.

Name, Role, Value (4.1.2)

For all UI components — form inputs, buttons, custom widgets — three things need to be programmatically determinable:

Name: What is this thing called? The accessible name is what screen readers announce when focus lands on the element. For a button with visible text, the name is that text. For an icon button, you need something else, such as an aria-label, a visually hidden span, or a <title> in an SVG.
Role: What kind of thing is this? Is it a button, a link, a checkbox, a text input? Semantic HTML handles this automatically. A <button> has a button role. An <a> has a link role. A <div> that's been styled and scripted to act like a button has no role unless you explicitly give it one. Again, ARIA can help here.
Value: What is its current state? For things like checkboxes, toggles, menus, or sliders, users need to know the current state — checked/unchecked, expanded/collapsed, selected/unselected. HTML handles this for native elements. Custom widgets need aria-checked, aria-expanded, aria-selected, and similar attributes to communicate it.

The principle isn't complicated: communicate the 'what', the 'what kind', and the 'what state' of every interactive element. The challenge is that it's easy to forget when building custom components, especially when you're writing a <div> that looks like a button because you needed it to look a certain way.

What success looks like

All UI components have a determinable name, role, and state, and those can be set by the user where appropriate. (4.1.2 — Level A)

Status Messages (4.1.3)

Status messages — confirmations, alerts, progress indicators, error notifications — need to be communicated to assistive technology without requiring focus to be moved to them.

When a form submission succeeds and "Your message was sent" appears at the top of the page, sighted users see it. But a screen reader user who just submitted the form is still focused on the submit button. If that status message isn't programmatically flagged, the reader won't announce it, and the user has no feedback that anything happened.

ARIA live regions handle this. role="status" and role="alert" (or aria-live) mark content as something that should be announced when it updates, without needing the user to navigate to it. role="alert" is for urgent things (errors). role="status" is for polite notifications (success messages, progress updates).

The important nuance here is that this criterion doesn't apply to changes in focus; those are announced automatically. It applies specifically to messages that appear without focus moving to them.

What success looks like

Status messages can be determined by assistive technology without receiving focus. (4.1.3 — Level AA)

The throughline

Robust asks a different question than the other three principles. Perceivable, Operable, and Understandable are about users' direct experience of your content. Robust is about the tools they use to access that content — whether those tools can correctly interpret what you've built.

The reason this matters is that you never fully control how your content is rendered. Screen readers, browser extensions, voice control software, refreshable Braille displays, older browsers — these all have to parse your HTML and make inferences from it. The more standards-compliant your markup is, the more reliable those inferences are. Robustness isn't glamorous, but it's what makes the rest of the work actually hold up in the wild.

Going Deeper

Robust — Understanding WCAG 2.2 — W3C's full breakdown
How to Meet WCAG — Robust — filterable checklist
Using ARIA (W3C) — the authoritative guide to when and how to use ARIA, including the five rules
ARIA Authoring Practices Guide (APG) — patterns for building common custom widgets accessibly, with code examples

Sources

W3C. "What's New in WCAG 2.2." https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/ (accessed May 2026) ↩