With the three previous principles we have covered what the person perceives, operates, and understands. But all of that rests on one technical condition: that the content be built so that browsers and assistive technologies interpret it reliably, today and in the future. That is the fourth and final POUR principle, Robust. It has the fewest criteria and is the most "plumbing"-like, but the most critical: if the code is not robust, a component can be visually perfect and still not exist for Marta and her NVDA. Here we connect directly to the accessibility tree we saw in Module 2.

1. What "robust" means
2. Guideline 4.1: Compatible
3. The link to the accessibility tree
4. Success criteria summary table
5. Common mistakes and tips
6. Exercises
7. Conclusion and module wrap-up

Robust means the content must be able to be interpreted reliably by a wide variety of user agents, including present and future assistive technologies. It is not enough that it "looks good in my browser": the markup must expose information that any assistive technology can read, now and when new versions of readers, browsers, or devices appear. Robustness is what makes your accessibility work survive over time.

Maximize compatibility with current and future user agents.

Historically, 4.1.1 required well-formed markup (no duplicate ids, tags properly nested and closed). In WCAG 2.2 this criterion was marked obsolete and removed. Why? Because modern browsers and assistive technologies already recover robustly and consistently from the markup errors this criterion aimed to prevent: the HTML specification defines how to parse imperfect code, so those flaws no longer break accessibility on their own. The problems that do matter (for example, a duplicate id that breaks an aria-labelledby association) are covered by other criteria such as 4.1.2 or 1.3.1. Practical takeaway: do not chase markup validity as an end in itself; chase getting name, role, and value right.

This is the central criterion of robustness. For every interface component—especially custom ones—assistive technology must be able to determine:

• Name: what it is called ("Filter by category").
• Role: what it is (a button, a dropdown, a checkbox).
• Value/state: what situation it is in (open/closed, selected, expanded).

With native HTML this comes for free: a <button> or a <select> already exposes its name, role, and state. The problem appears with components hand-built from <div> and JavaScript: with no role, no accessible name, and no ARIA states, they are empty shells to assistive technology.

Status messages—confirmations, errors, results, progress—must be able to be announced to assistive technology without moving focus. When Cursalia shows "12 courses found" after filtering, or "Enrollment saved", Marta must hear it even though her focus is still on the filter. Technically this is achieved with "live" regions (for example aria-live), but here it is enough to hold on to the requirement.

In Module 2 we saw that assistive technology does not read the visual DOM, but the accessibility tree: a representation the browser builds by exposing the name, role, and state of each element. The Robust principle is, literally, the requirement that this tree be well populated.

Imagine Cursalia's filter dropdown built with <div>s and no semantics. Visually it works: it opens, closes, highlights the chosen option. But in the accessibility tree there is no "button", no name, no "expanded" state. Marta tabs and NVDA announces... nothing useful, or a plain "clickable". The control is invisible to her. The conceptual solution is to give it correct name/role/value: use native HTML whenever possible, and when you cannot, apply ARIA to declare role and state.

The semantic HTML and ARIA that implement name/role/value are Module 4: Semantic HTML and ARIA. Robust behavior in dynamic content and SPAs (announcing changes, managing focus when navigating between views) is explored in depth in Module 7.

• Reinventing controls with <div> and <span>. A <div onclick> is not a button to assistive technology. Always start from the native element (<button>, <select>, <input>), which brings name/role/value out of the box.
• Believing 4.1.1 still requires "valid HTML". In WCAG 2.2 it is obsolete; what matters is that name/role/value come through correctly. Even so, avoid duplicate ids because they break ARIA associations (that is penalized by 4.1.2 and 1.3.1).
• Adding ARIA without managing state. Declaring role="button" but not updating aria-expanded leaves the value lying. The golden rule: no ARIA is better than bad ARIA.
• Showing messages that can only be seen. A "Saved" that appears visually but is not announced violates 4.1.3; Marta never learns that her action worked.
• Tip: for any component, ask yourself three questions —does it have a name? do you know what it is? do you know its state?—. If any of them fails, it is not robust.

Exercise 1. Cursalia's filter dropdown is built with <div> and JavaScript; visually it opens and closes a panel of options. With NVDA, Marta does not perceive that it is a control or whether it is open. Which criterion is violated, and what three pieces of information must the component expose?

Exercise 2. After applying the filter, the text "12 courses found" appears, but Marta, whose focus is still on the control, hears nothing. Which criterion applies, what level is it, and what does it require?

Exercise 3. A colleague proposes auditing the site by validating the HTML with the W3C validator to "comply with 4.1.1". What would you explain to them about the status of that criterion in WCAG 2.2, and where should the effort be redirected?

Solution 1. This violates 4.1.2 Name, Role, Value (A). The component must expose: a name (e.g. "Filter by category"), a role (that it is a dropdown control/button that opens a list), and a value/state (whether it is expanded or collapsed, and which option is selected). Implementation with native HTML or ARIA is covered in Module 4.

Solution 2. 4.1.3 Status Messages (AA) applies. It requires the status message to be announced to assistive technology without moving focus, typically through a live region, so Marta hears it while she keeps working in the filter.

Solution 3. I would explain that 4.1.1 (parsing) is obsolete and was removed in WCAG 2.2: browsers already reliably recover imperfect markup, so validating HTML is not what guarantees accessibility. The effort should be redirected to 4.1.2 (getting name/role/value right on every component) and 4.1.3 (status messages). Validity is still good hygiene—especially avoiding duplicate ids—but it is not a criterion in itself.

The Robust principle is the technical guarantee of everything above: without correct name/role/value and without announceable status messages, the other three principles stay on the visual surface and never reach the accessibility tree Marta uses. With this we close Module 3: we have walked through the four POUR principles, understanding what each one requires and its key WCAG 2.2 criteria, with their A/AA levels.

Up to here we have talked about requirements. From Module 4 on we shift plane: we move from "what WCAG requires" to "how it is implemented in HTML and CSS". We will start with semantic HTML—the most direct and robust way to get name/role/value for free—and continue with accessible forms, ARIA, and contrast. Everything that in this module we deferred with a "implemented in Module 4/5" starts to be built now, with real code.