How to test what your agent knows about accessibilityHow to test what your agent knows about accessibility

Running axe against pages that agents wrote on this site has caught color contrast failures, missing names and labels, heading and landmark structure problems, and keyboard and focus issues. I found those four categories in my own code, written by an agent, in pages that looked correct in a screenshot. That is why a design engineer still needs some accessibility knowledge by hand: an agent can build a menu that looks identical to a good one, behaves correctly under a mouse and fails a keyboard user, and nothing in a screenshot, a demo or a casual review will say so.

What automated checks can and can't see

A Playwright test on this site fails the build if any public route has a serious or critical axe violation against the WCAG 2.0 and 2.1 A and AA rule sets, in both light and dark mode, and a second test checks that the first Tab stop on the home page is the skip link. The comments in the axe test record something worth knowing before you copy it: every route gets a fresh browser context, because reusing one page lets the previous route's styles linger, and axe then measures the next route mid-style-injection and reports contrast failures that aren't real (the comments note the flagged elements compute to 5.5:1 once the page settles).

Cambium, the accessibility audit platform I'm building under Sargent Design, combines axe-core for the criteria a program can determine with AI-powered coverage for the ones it can't, modeled on the workflows in Microsoft's Accessibility Insights. A scanner can tell you an image has no alt attribute and can't tell you the alt text is useless, and it can tell you a control has no accessible name and can't tell you the name is misleading. Contrast is the one category that reduces to arithmetic, and this site checks its color pairings with a unit test that the handoff piece describes.

What the published sources say

A practical guide on agentic AI, design systems and Figma warns that missing states produce agent-built components that can't be interacted with or that show errors. A LogRocket review of AI in UX writing found that AI defaults to weak patterns like "Click here" and a bare "Submit," and that explicit accessibility prompts didn't reliably balance clarity, concision and assistive technology support.

A test to run on your own work

Pick five patterns that go wrong most often: a dialog, a set of tabs, a menu, a form with validation errors and a data table. Build each in three conditions: no accessibility instruction at all, an explicit instruction to make it accessible, and your design system's components and rules file in place. Check every result four ways (an automated scan, a keyboard-only pass, a screen reader pass and a read of the visible and accessible text) and score each as pass or fail, which gives fifteen builds and sixty checks. Write down in advance which result would change your mind. If the second condition fixes labels and alt text and leaves focus management alone, the instruction is cosmetic and the rules file has to carry the structural work, and if the third condition still fails the dialog, the design system has a gap to fix at its source.

What to learn by hand

Native elements come first, because the cleanest fix for most agent-built widgets is to replace a div wearing a role with the real element, and when ARIA helps and when it hurts is the long version of that argument. Focus management comes next: where focus goes when a dialog opens, closes, or loses the content it was sitting in is invisible in a mockup and decisive in use, and focus management is the accessibility thing everyone forgets covers it. A designer can check tab order, visible focus, escape and arrow-key behavior in two minutes without reading code, using the keyboard navigation piece. Link text, button labels and error messages need a person who reads them closely, since that is the area the LogRocket review flagged and scanners cannot judge.