An open letter to AI tool creators, business leaders, and engineering and design stakeholders.
A person should not lose access to a service because its software has changed.
A payment form that worked with a keyboard yesterday should still work today. A control that had a clear name should keep its meaning after a redesign. An update should preserve someone’s ability to understand information, make a decision and complete a task.
When that access disappears, people bear the cost. They must find another route, ask for help, report the same barrier again—or go without.
Software development is accelerating. AI can help teams create and change interfaces faster. That opportunity comes with a responsibility: the speed of delivery must not outpace our ability to preserve access.
We call on AI tool creators, business leaders, and engineering and design stakeholders to make accessibility a requirement that survives change. Each has a part to play: define what people need, carry those requirements into software, and provide evidence that access is preserved.
Start with people’s requirements
Describe what people need to understand, do and experience before choosing an implementation.
Include disabled people in shaping those requirements. Resource their participation and respect their expertise. Give accessibility professionals the authority and time to influence decisions throughout delivery.
People should not have to repeatedly prove that their access matters.
Preserve reviewed decisions
When an accessible interaction has been designed, implemented and reviewed, record what matters and why.
Make those requirements available to the designers, developers and AI systems that change the product next. Carry them through redesigns, component replacements and platform migrations.
Access should not depend on one person remembering a decision made months ago.
Check what changes
Evaluate the effects of an update on accessibility before release. Combine automated checks with expert review, assistive-technology testing and testing with disabled people where needed.
When a change introduces a barrier, make it visible, assign responsibility and address it.
Provide a clear way for people to report problems, and act on what they tell you.
A previous review is evidence about a previous version. Maintaining access requires continued attention.
Be honest about evidence
State what was tested, what was found and what remains uncertain.
Distinguish automated checks from human review. Record the scope and limitations of both. A passing check must not become a claim that every person can use an entire service.
Clear evidence helps teams make better decisions. It also helps people understand what they can reasonably expect.
Keep responsibility with people
AI can support accessibility work. Organisations remain responsible for the services they deliver.
AI tool creators: make it possible for teams to supply accessibility requirements, preserve reviewed decisions through generated changes, and inspect what changed. Make the limits of your tools clear.
Business leaders: fund accessibility throughout delivery, assign accountability, and resource disabled people’s participation. Give teams the time and authority to address barriers.
Engineering stakeholders: carry accessibility requirements into code, components and release decisions. Verify changed behaviour and address regressions before they become someone else’s barrier.
Design stakeholders: define accessible interactions with disabled people. Record the intent behind decisions, including keyboard behaviour, focus and content, and preserve it through implementation.
Automation should support professional judgement and participation by disabled people. Responsibility cannot be delegated to a tool.
Turn support into action
We ask AI tool creators, business leaders, and engineering and design stakeholders to publish how they will meet these commitments: who is responsible, what they will change, and how progress will be assessed.
Begin with a service, product or workflow. Establish its accessibility requirements. Record reviewed decisions. Check subsequent changes against them. Share what improves access and what still needs work.
ShapeA11y advocates open infrastructure for accessible software. We will apply these principles to our own work: make our approach open to scrutiny, explain the limits of our evidence, and revise our assumptions when findings challenge them.
Supporting this letter does not require adopting ShapeA11y’s tools. It means supporting a shared expectation:
People’s access must remain a requirement as software changes.
More software is not enough. Faster delivery is not enough. Progress means more people can participate—and continue to participate after the next update.
Accessibility should survive the change.
Design. Build. Include.
ShapeA11y ·