Accessibility Checklist for Your AI-Generated App
AI-generated interfaces often ship missing labels, low contrast, and broken keyboard flows. A practical accessibility checklist to run before launch.
An AI-generated interface usually looks finished the moment it renders. Look closer and the gaps cluster in the same places every time: form fields with no labels, buttons that are only icons, color choices that fail contrast checks, interactions that silently assume a mouse. None of this reflects badly on the agent so much as on the prompt — accessibility is rarely requested, so it's rarely produced. The fix is a short checklist you walk before shipping, plus telling the agent these requirements up front. What follows covers the basics that catch the large majority of real problems.
Labels on every input
The single most common miss. A placeholder sitting inside an empty field is not a label — it disappears as soon as someone types, it often fails contrast, and screen readers may not associate it with the field at all. Every input needs a proper label element tied to it (or an aria-label when visual space doesn't allow one). Check the same for selects, checkboxes, radio groups, and date pickers. While you're there, make sure error messages are attached to the field they describe rather than rendered somewhere far away, since an unattached "this field is required" helps no one.
Connect the Claude or Codex you already pay for — the rest runs on workers that cost a fraction.
Download meshcode →Color contrast and don't rely on color alone
Low-contrast gray-on-gray text is endemic to generated UIs because agents reach for muted palettes that photograph well in screenshots. The WCAG AA standard sets the widely used thresholds: roughly 4.5:1 contrast for normal body text and 3:1 for large text. Run a contrast checker over your palette rather than eyeballing it. The second half of this item matters just as much: state must never be communicated by color alone. A red border is not an accessible error indicator unless it comes with text or an icon; the same goes for links that differ from surrounding text only by hue.
Keyboard navigation and visible focus
Unplug the mouse mentally and walk the whole app: tab through every page and confirm you can reach each interactive element, in a sensible order, see where focus currently sits, and operate everything — open menus, submit forms, dismiss dialogs — without pointing and clicking. Two classic failures to hunt for: custom dropdowns and modals built from divs that ignore keyboard events entirely, and focus styles removed because somebody thought the outline looked untidy. Never delete the focus outline without replacing it with something more visible. Modals should also move focus into themselves and return it where it came from when closed.
Alt text and accessible names
Images that carry information need alt text describing that information; purely decorative images need empty alt attributes so screen readers skip them instead of announcing a filename. The related failure that AI-generated UIs produce constantly: icon-only buttons. An icon of three dots or a trash can means nothing to a screen reader unless the button has an accessible name. Ask the agent to audit every icon-only control and give each one a name. The same principle covers links whose entire visible text is "click here" — the link text should describe the destination, because many users navigate by listening to links out of context.
Structure: headings, landmarks, semantic elements
Underneath the visuals, assistive technology reads structure. One <h1> per page, heading levels that don't skip around, real <button> and <a> elements instead of clickable divs, table headers marked as such, and form controls grouped into fieldsets where it helps. Semantic HTML is also where agents can be most easily corrected once and trusted afterward: put "use semantic HTML elements, headings in order, and real buttons and links" into your conventions file and most future violations disappear before they're written — the same principle behind keeping an AI agent from breaking existing code.
How to test without building a lab
Three passes cover the ground surprisingly well. First, keyboard-only: navigate your critical flows with Tab, Enter, Escape, and arrow keys. Second, zoom the browser to 200% and confirm nothing important is clipped or overlaps. Third, turn on your operating system's built-in screen reader and spot-check the main flows — you don't need expertise to hear that a form announces nothing useful. Automated checkers catch only a subset of issues (they check that alt attributes exist, not whether they're any good), so treat them as a floor, not the finish line. A cross-model review setup, where a different model reviews the first agent's markup, is a cheap way to catch what the original author normalized away.
The meshcode angle
This checklist is exactly the kind of multi-page sweep worth delegating. meshcode is a native desktop app for macOS and Windows where each pane runs its own agent session, so one pane can fix labels and alt text across views while another runs the keyboard-only pass and patches what breaks — all in the same repo. Drive the Claude Code or Codex CLI subscription you already have, or meshcode's metered models billed pay-as-you-go with no monthly fee.
👉 Download meshcode — Mac, Windows