Build with AI
How to review AI-generated UI for accessibility
A practical first-pass accessibility review for generated interfaces, covering keyboard use, labels, content structure and state changes.
Review the running interface
Start an accessibility review of AI-generated UI with the actual rendered page and a task someone should complete. A screenshot cannot tell you whether a button has a meaningful name, keyboard focus is visible or a validation error is announced.
W3C’s Easy Checks is a useful first review covering issues such as headings, contrast, labels and keyboard access. It explicitly does not establish full accessibility. Treat a quick review as a way to find problems and plan deeper evaluation, not as a compliance certificate.
Walk one task with the keyboard
Choose a concrete task, such as editing a notification preference. Move through the page using the keyboard, operate the control, save and leave the page. Record where focus becomes difficult to see, moves unexpectedly or enters something you cannot exit.
Check that interactive controls use appropriate elements and understandable names. A clickable icon that a sighted person recognizes can still be unclear without its visual context. Do not ask the agent to fix every issue by adding ARIA attributes; first inspect the underlying element and behavior.
Inspect content and feedback
Read the heading order as an outline. Verify that form controls retain labels while values are entered. Try an invalid submission and check whether the error explains how to correct the input. Increase text size and inspect whether content or actions disappear.
For updates that happen without a page change, review how meaningful status is communicated. A saved message, a search-result count and a failure notice need deliberate treatment. Use the relevant W3C guidance rather than turning the entire application into a live announcement region.
Ask the agent for evidence and bounded fixes
Give the agent the route and task, and ask it to separate observations from assumptions. If a screen reader or browser check was not performed, the report should say so.
Review this running interface for a first-pass accessibility check. Task: change a notification preference and confirm it saved. Inspect keyboard order and focus, control names, labels, headings, text resizing and error/status feedback. For each finding, give the observed behavior, affected task and a focused fix. Use existing semantic components where possible. Do not claim WCAG conformance or a screen-reader pass without the corresponding evaluation. After changes, repeat the affected interaction.
Keep design references in the right role
Taste references can help clarify hierarchy or demonstrate a layout with readable spacing. They are not accessibility evidence. A screenshot of another product may hide keyboard, contrast or semantic problems. Preserve useful visual ideas while checking the implementation independently.
Record unresolved issues and the environments you actually tested. Automated checks, manual review and feedback from people with disabilities answer different questions. Use a broader evaluation when the product and its users require it.