Accessibility is not a nice-to-have polish pass.
It is part of whether people can use the thing you built.
It also overlaps heavily with good mobile UX, SEO, conversion and trust. A form with no label is bad for screen readers, but it is also bad for anyone trying to understand what to type.
AI-built apps often produce attractive components with weak accessibility underneath.
Start with forms
Forms are where accessibility issues turn into lost users.
Check:
- every input has a label or accessible name
- errors are visible and specific
- required fields are clear
- autocomplete is appropriate
- keyboard focus moves sensibly
- disabled states are understandable
- success and failure states are announced or visible
Search:
rg "<input|<textarea|<select|<label|aria-label|aria-describedby"
Ask:
Review every form in this app for accessibility and mobile usability.
For each form, check:
- label association
- accessible name
- error messages
- required fields
- autocomplete attributes
- keyboard flow
- mobile keyboard behaviour
- loading and success states
Check buttons and links
Buttons do things. Links go places.
AI-generated UIs sometimes use clickable div elements, empty buttons, icons without labels, or links that behave like buttons.
Ask:
Review interactive elements.
Find:
- clickable divs that should be buttons or links
- icon-only buttons without labels
- buttons with unclear text
- links used for actions
- buttons used for navigation
- missing focus states
- disabled controls without explanation
This is basic, but it affects real users immediately.
Test keyboard access
Put the mouse away.
Use:
- Tab
- Shift Tab
- Enter
- Space
- Escape
- arrow keys for menus where appropriate
Try to complete the main action.
Ask your agent:
Create a keyboard-only test plan for this app.
Include navigation, menu opening and closing, forms, modals, checkout or signup, error states and focus return after dialogs close.
If you cannot complete the important flow with a keyboard, the app is not launch-ready.
Check colour contrast
Low-contrast text is common in polished AI-generated designs.
The design looks subtle. The user reads it on a phone in daylight and gives up.
Ask:
Review text and UI colour contrast.
Flag low-contrast body text, placeholder-like labels, disabled-looking active controls, subtle links, badges, secondary buttons and text over images or gradients.
Suggest concrete colour/token changes.
Do not accept "make it darker" as the only answer. Ask for the exact class, token or colour value.
Mobile tap targets
Small tap targets are frustrating.
Check:
- header nav
- footer links
- pricing toggles
- checkboxes
- radio buttons
- icon buttons
- close buttons
- carousel controls
- form controls
Use this prompt:
Review mobile tap targets.
Find controls smaller than comfortable touch size, controls too close together, and controls that move or become hidden when the mobile keyboard opens.
Recommend layout fixes that preserve the design.
Images need alt text
Not every image needs descriptive alt text.
Decorative images can use empty alt text. Informational images need useful descriptions.
Ask:
Audit image alt text.
For each image, decide whether it is decorative or informative.
If informative, write alt text that explains the purpose of the image in context.
If decorative, make sure it does not create noise for screen readers.
What PageLens can help with
PageLens checks accessibility and UX signals from the rendered page, including common issues around forms, labels, contrast, mobile usability and evidence visible in the DOM.
It is not a full manual accessibility audit. But it catches the practical issues that make AI-built apps feel unfinished or hard to trust.
Run it before launch, fix the quick wins, and re-scan.
Accessibility work is not only compliance.
It is product quality.