How to make AI-generated interfaces accessible

To make AI-generated interfaces accessible, ask for the right structure up front, then check what was built rather than trusting it. Most problems in generated UI are basic and fixable: clickable divs instead of buttons, inputs without labels, removed focus outlines, low-contrast secondary text and custom widgets that don’t work with a keyboard. Automated tools find some of these; a short manual pass with a keyboard and a screen reader finds the rest. No tool can certify that a page is accessible on its own.

Set the floor before generating

Put your accessibility requirements where the agent always sees them, such as your CLAUDE.md. Rules that can be checked work better than “make it accessible”:

## Accessibility (target: WCAG 2.2 AA)
- Native elements first: <button> for actions, <a href> for
  navigation, <label> for every input. No click handlers on divs.
- One h1 per page; headings in order without skipping levels.
- Never remove focus outlines without a visible replacement.
- Text contrast at least 4.5:1 (3:1 for large text). UI component
  and focus indicator contrast at least 3:1.
- Interactive targets at least 24 by 24 CSS pixels.
- Errors are shown in text next to the field, say how to fix them,
  and are announced. Colour is never the only signal.
- Images: meaningful alt text, or alt="" if decorative.
- Use ARIA only when no native element does the job, and only
  with the keyboard behaviour it promises.

Semantic structure

Semantics are what assistive technology reads. Check for landmarks (header, nav, main, footer), a sensible heading outline, lists marked up as lists and tables marked up as tables with header cells. Generated code often uses a heading level for its size rather than its place in the outline; style and level should be separate decisions.

Keyboard navigation

Everything you can do with a mouse must work with a keyboard. Native buttons, links and inputs do this for free, which is the main reason to insist on them. Custom components (menus, comboboxes, tabs, dialogs) are where generated code most often fails: they look right and can’t be reached or operated.

• Tab moves through interactive elements in a logical order.
• Enter and Space activate buttons; arrow keys move within menus, tabs and listboxes.
• Escape closes dialogs and menus, and focus returns to what opened them.
• Dialogs keep focus inside while open.

If your project uses an established component library with accessible primitives, tell the agent to use it rather than build widgets from scratch.

Focus visibility

Generated styles sometimes include outline: none for a cleaner look. Focus must stay visible, with enough contrast against its surroundings. WCAG 2.2 also adds Focus Not Obscured (Minimum): a focused element mustn’t be entirely hidden by author-created content, a common problem with sticky headers and cookie banners.

Colour contrast

WCAG 2.2’s contrast minimum is 4.5:1 for normal text and 3:1 for large text. Generated palettes tend to fail on muted metadata, placeholder text, disabled-looking buttons and text over images. Interface components and graphical objects, such as input borders and icons that convey meaning, have their own non-text contrast requirement of 3:1. Check in both light and dark themes if you have them.

Forms and error messages

• Every input has a visible label tied to it. Placeholders aren’t labels.
• Required fields are marked in text, not only with colour or an asterisk without explanation.
• Errors appear next to the field, describe the problem and the fix, and are connected to the input (for example with aria-describedby).
• On submit, focus moves to the first error or an error summary.
• Autocomplete attributes are set for common fields such as name and email.

Touch targets

WCAG 2.2’s Target Size (Minimum) requires pointer targets of at least 24 by 24 CSS pixels, with exceptions including adequate spacing and inline links. Small icon buttons in dense generated UI are the usual offenders. Responsive layouts make this worse; see making AI-generated UI responsive.

ARIA, used sparingly

AI-generated code tends to add ARIA attributes generously. That can make things worse. The W3C’s ARIA Authoring Practices open with a section titled “No ARIA is better than Bad ARIA”, and point out that, unlike native HTML elements, “ARIA roles do not cause browsers to provide keyboard behaviors or styling.” A div with role="button" still needs keyboard handling written by hand. Prefer the native element.

Automated versus manual testing

Automated checkers are fast and catch many structural issues: missing labels and alt text, some contrast failures, invalid ARIA, duplicate IDs. They’re worth running on every change. They can’t judge whether alt text is meaningful, whether focus order makes sense, whether an error message helps, or whether a custom widget actually works. The W3C is direct about this: “Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so.”

A practical split:

• Automated, every change: an accessibility checker in your test suite or browser, plus lint rules for JSX accessibility.
• Manual, every new screen: keyboard-only pass, zoom to 200% and 400%, a screen reader pass on key flows.
• With users, periodically: nothing replaces testing with disabled people who use assistive technology daily.

Agents can help with the manual pass. Ask Claude to tab through a page in the browser and report the focus order, or to list every interactive element and its accessible name. Our visual testing guide includes a tested Playwright check that focus is visible.

Review checklist for generated UI

1. Actions are buttons, navigation is links, inputs have labels.
2. One h1; headings in order; landmarks present.
3. Every interactive element is reachable and usable by keyboard, in a logical order.
4. Focus is always visible and never hidden behind sticky elements.
5. Dialogs trap focus, close on Escape and return focus.
6. Text contrast meets 4.5:1 (3:1 large); component and focus contrast meets 3:1.
7. Colour is never the only way information is shown.
8. Errors are in text, specific, linked to fields and announced.
9. Targets are at least 24 by 24 CSS pixels or adequately spaced.
10. Content reflows at 320 CSS pixels wide without page-level horizontal scrolling.
11. Images have appropriate alt text; decorative images have empty alt.
12. ARIA is only used where needed, and its keyboard behaviour is implemented.
13. Motion respects prefers-reduced-motion.
14. An automated check passes, and a manual keyboard and screen reader pass is done.

Set the floor, then test by hand

Accessible generated UI starts with a clear floor in the instructions, native elements over clever ones, and a review that includes a keyboard and a screen reader. Treat automated results as a first filter, not a verdict.

When Attuna, which is in development, gives an agent a project’s creative direction, accessibility and function are ranked above project rules and style preferences, so a principle like “lighter, quieter text” never outranks contrast.