WCAG Robust

Robust is the fourth WCAG principle. Content keeps working across browsers and assistive technology, both now and as they change. For AI the risk is that generated markup is sloppy, or that ARIA is misused, so assistive technology cannot read the result correctly.

Key points

Robust means content keeps working across browsers and assistive technology, now and as they change.
Every custom control must expose its name, role, and state, which is where many AI chat interfaces fail.
Generated HTML must be valid and semantic, and models do not produce that by default, so guide and check it.
Use ARIA only to fill a real gap, not to add keywords or paper over the wrong element.
The same logic applies to any prebuilt component library, reach for native HTML first and evaluate the library rather than trusting its reputation.
A passing validator is not proof, so test with real screen readers like JAWS, NVDA, and VoiceOver.

Name, role, and value

Every custom control has to expose its name, its role, and its current state to assistive technology, under criterion 4.1.2. AI chat interfaces are full of custom controls, so this is where many of them fail. In one well-known example, an audit of ChatGPT’s own interface found that the prompt field and the send button had no accessible label, so a screen reader user could not tell what they were for. Give every control a clear name and the right role, and prefer a real element over a generic one with attributes bolted on.

Valid, semantic markup

Generated HTML should be valid and should use the right elements for the job. Models do not produce accessible markup by default. So you have to guide generation and then check the result, rather than trusting that it came out clean.

Use ARIA honestly

ARIA is for describing meaning that native HTML cannot express on its own. It is not a place to add keywords or to paper over the wrong element. Adrian Roselli warns that pushing developers to add ARIA so AI bots can read a page leads to abuse, and that sites which lean on ARIA are on average less accessible, not more. Reach for a real button before a div with a button role. If you point an AI coding tool at the ARIA Authoring Practices Guide, note Eric Bailey’s caution that the guide is a showcase of what ARIA can do, not a tested pattern library, and that its code samples range from fine to broken.

The same caution applies to component libraries

The first rule of ARIA is not to use ARIA. A parallel rule holds for prebuilt frontend component libraries. Reach for native HTML first, and treat one of these as a last resort for the small set of widgets HTML has no native element for, such as a combobox or a tab panel. This caution is not about frameworks in general. A framework like Astro, Eleventy, or React is a tool for structuring and reusing markup, and choosing one is mostly orthogonal to accessibility. The caution is specific to libraries that ship prebuilt widgets, because their accessibility quality varies widely and is easy to lose in customization. A 2026 audit of shadcn/ui found the underlying Radix primitives it wraps to be accessible on their own, but shadcn’s default styling undoes some of that work, for example by rendering focus rings at 2.4 to 1 contrast against a 3 to 1 requirement, and by wrapping at least one component with no accessible alternative for screen readers. Because these libraries are usually copied into your own codebase rather than installed and upgraded, a gap like that becomes yours to find and fix. Evaluate a library by the components you actually ship, not by the reputation of what it is built on, and test the result with a real screen reader before you trust it.

Status messages

When content updates on its own, such as a streaming answer or a background result, the update is a status message under criterion 4.1.3. It has to reach assistive technology without moving the user’s focus, which is the job of a live region. The technical details sit in WCAG Perceivable and the streaming pattern.

Compatibility over time

Robust also means the content keeps working as browsers and assistive technology change. Passing an automated validator is not the same as working in JAWS, NVDA, or VoiceOver. Automated checks miss things that only show up when a real screen reader reads a real page, so test with actual assistive technology as well. See Automated tools and Manual testing.

Audience: Engineer

Robust is mostly about discipline with markup. Use native elements first, and add ARIA only to fill a real gap. The same discipline applies one level up, at the component library the model reaches for. A copy-paste UI kit built on a solid primitive can still ship a broken customization, so audit the components you actually use rather than trusting the primitive’s reputation. Make sure every custom control reports its name, role, and state, and verify that in an accessibility inspector rather than by eye. Treat the model as a junior author. It will produce a flat or mislabelled structure unless you instruct it and review the output, and a clean validator run does not prove it works in a screen reader.

Audience: Accessibility Specialist

The Robust failures in AI products cluster around two things, unlabelled custom controls and ARIA misuse. Inspect the accessibility tree for the chat controls and the rendered output, and watch for roles applied to the wrong elements or redundant ARIA that fights the native semantics. Always confirm findings with a real screen reader, because the gap between a passing validator and a usable page is exactly where these products break.

Audience: Designer

Robustness starts in the component design, not only the code. When you specify a control, specify its name, its role, and its states, including the busy or loading state during generation, so the build has an accessible target to hit. A stop affordance that is only an icon, or a confidence pill that is only a color, will not survive into the accessibility tree unless the design names what it means.