A booking form appears. Another prompt adds a date picker. Another changes the layout and replaces the submit button. The screen looks ready.
Can someone finish the booking without a mouse? Does the date picker make sense to a screen reader? When a time slot becomes unavailable, does the person know what happened and how to continue?
Generating the interface has not answered those questions. As AI makes it easier to produce and revise software, teams need a way to carry accessibility requirements through each revision. Otherwise, the distance between what has been built and what has been checked can keep growing.
Every change can affect someone's access
Consider a familiar request: “Make this form cleaner.” An assistant might remove visible labels, replace a standard control or move an error message. Each choice could affect how someone understands or operates the form, even if the new layout looks better.
The same risk exists in human-written software. Frequent generation and revision make it especially important to preserve the behaviour that already works. A review of yesterday's version cannot establish that today's version remains accessible.
For the person using the service, the consequence is immediate: a task they could complete yesterday may now require help, or may no longer be possible.
Put accessibility in the request
“Make it accessible” leaves too much unstated. Give an assistant concrete requirements alongside the feature itself: what the person needs to do, which existing components to use and which behaviours must survive the change.
For a booking form, that request might be:
Build the booking form using our reviewed form components. Give every field a visible label. Make the complete journey operable with a keyboard and keep focus visible. Explain errors in text and associate them with the relevant fields. Preserve entered information after an error. Make booking progress and confirmation available to screen-reader users. Describe what you tested and what still needs human review.
These instructions make expectations inspectable. They do not guarantee the result. The next step is to check the implemented journey against them.
Keep those requirements in the project, component guidance and review criteria so the next prompt does not have to reconstruct them from memory.
Make useful checks part of every change
Run repeatable accessibility checks while the work is still being developed. Inspect control names, page structure, keyboard behaviour and the states a customer will encounter. When a barrier is fixed, add an appropriate regression check so a later change is less likely to reintroduce it.
Test beyond the first screen. Submit an empty form. Trigger an error. Open and close the date picker. Try an unavailable option. Follow the journey through loading, failure and success. A page can behave differently in each state.
Automation helps teams repeat checks consistently, but its coverage has limits. W3C explains that no tool alone can determine whether a site meets accessibility standards. A passing result must be read alongside what the tool actually examined. W3C accessibility evaluation guidance.
An assistant saying “accessibility checked” should lead to evidence: which page, which state, which checks and which unresolved findings.
Give people time to review what matters
Fast generation still needs review capacity. If a team produces more changes than it can meaningfully check, it needs smaller changes, more review capacity or a slower release pace.
Start with the tasks people depend on: signing in, buying, booking, paying and getting help. Review changed interactions with a keyboard and relevant assistive technologies. Include comprehension, error recovery, zoom and motion in the review where they matter to the experience.
Involve disabled people early enough for their feedback to influence the design. Pay for their expertise and provide accessible ways to participate. User evaluation and standards-based review inform each other; one participant's experience cannot represent every disability or establish conformance on its own. W3C guidance on involving users in evaluation.
Keep responsibility with the team
AI can help draft requirements, suggest patterns and investigate failures. People still decide what ships, what evidence is sufficient and who owns unresolved barriers.
Product leaders need to resource that work. Designers need to specify behaviour beyond appearance. Engineers need to preserve it through implementation. Reviewers need time and access to the actual product. AI tool creators can support this by making requirements, inspection and verification part of their workflows.
Record what was tested, against which version, and what remains uncertain. Those records give the next person a useful starting point when the software changes again.
Why ShapeA11y works here
ShapeA11y brings accessibility requirements and inspection into the work of building software. Rules and skills give assistants concrete expectations; tools help teams inspect the result and gather evidence for review.
That work supports a continuing loop: describe the need, build the interaction, check the behaviour, fix the barrier and preserve the improvement. Human judgement and lived experience remain part of it.
The aim is to make accessible decisions easier to repeat as the pace of development increases. A faster route from idea to interface should also carry a clear route from interface to something people can use.
Accessibility should survive the change.