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.
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. A Microsoft evaluation found that unguided model output passed automated accessibility checks only 12 percent of the time, rising to 86 percent only when the model was told to produce accessible code. 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.

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. 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.