Designing AI features for accessibility from day one
AI can remove barriers for some users and introduce new ones for others. Accessibility needs to be tested with real people and real tasks.
Topic diagram
Test the entire accessible user journey
Key takeaways
- Offer text, keyboard and other alternatives to voice-first workflows.
- Generated descriptions and transcripts need correction paths.
- Test across disabilities, languages, accents and assistive technologies.
- Include disabled users in research and evaluation.
Why this question matters
AI features can create useful new ways to interact with software, including speech input, image descriptions and simplified summaries. They can also fail for users with disabilities when they misrecognize speech, omit visual details, rely on color or produce content that assistive technology cannot navigate.
Design for multiple ways to interact
Do not make voice the only way to complete a task. Provide keyboard access, visible controls and text alternatives. Users should be able to review and correct a transcript or generated description instead of being forced to accept it as final.
Treat generated descriptions as fallible
Image descriptions can miss spatial relationships, text in an image or important context. Offer ways to inspect the original content and report errors. For critical information, avoid using a generated description as the only representation of a chart, warning or instruction.
Test speech diversity and noise
Speech systems can perform differently across accents, speech patterns, languages and recording conditions. Include diverse users and environments in testing. Provide fallback text input and let users edit recognized text before it triggers consequential actions.
Make generated content usable
Ensure headings, lists, links and tables remain structurally accessible. Check contrast, focus order, keyboard navigation and screen-reader announcements when AI-generated content updates dynamically. Do not let generated HTML or formatting bypass established accessibility controls.
Respect autonomy and privacy
Voice and image inputs can contain sensitive information. Explain processing and retention, avoid unnecessary recording and provide controls to pause or delete where appropriate. Accessibility features should not require users to surrender more data than the task needs.
Evaluate with disabled users
Automated checks are valuable, but they cannot substitute for testing with people who use assistive technologies. Include disabled participants in discovery and usability testing, and measure task completion, correction effort and failure recovery - not just whether the feature technically runs.
Common questions
Does voice input make a product accessible?
No. Speech recognition can introduce barriers, and users need alternatives, correction controls and a usable interface with assistive technology.
When should disabled users be involved?
During early design and throughout testing, not only after launch. Their task-based feedback can reveal barriers that automated checks miss.
Turn user research into release criteria
Accessibility feedback should lead to specific acceptance criteria. For example, a user should be able to reach the main action by keyboard, identify the current focus, correct a transcription without restarting the task and access the underlying text if an audio output fails. These criteria can be added to the product's normal test plan so they are checked again after interface or model changes.
Automated tools can identify some technical issues, but they cannot establish whether a generated description contains the information a person needs. Include task-based sessions with disabled users, and ask participants to explain where the system's interpretation helped or hindered them. Do not treat one person's experience as representative of every disability or access method. Use a range of participants and report the limitations of the research.
Provide a usable fallback
When the model cannot transcribe speech or interpret an image reliably, tell the user and offer another way to complete the task. Avoid blocking access to essential information behind an AI feature. Give users control over playback, timing, text alternatives and corrections where relevant. For important decisions, make the evidence and uncertainty visible and provide a way to request human assistance.
Accessibility is ongoing product work. Assign responsibility for reviewing user reports, prioritise barriers according to their effect and confirm fixes with the people affected. This is more credible than making broad inclusion claims based only on a checklist or a vendor's statement.
Questions for the accessibility review
Can users complete the task with a keyboard and their usual assistive technology? Can they correct a mistaken transcription or description? Is essential information available without using the AI feature? Have disabled users tested realistic tasks? Who will review barriers reported after release?
Turn the answers into specific acceptance criteria and repeat them after meaningful changes. If the team cannot explain how a user recovers from a model error, the design needs more work before launch.
Keep accessibility in the product backlog
Assign an owner to accessibility findings and track whether barriers are fixed before release. Prioritise issues that prevent people from completing essential tasks, and verify fixes with users or suitable assistive technology. Keep a non-AI route available when the generated output is unreliable or the feature is unavailable. Accessibility should not depend on whether a model happens to interpret a user's input correctly on a particular day.
When a new model or interface is introduced, rerun the key task scenarios. A change that improves general accuracy can still make a particular workflow harder to use. Track that possibility instead of assuming overall model quality guarantees an accessible experience.
Include accessibility in acceptance testing
Test the feature with keyboard-only navigation, screen readers, zoomed text, captions and alternative ways to provide or receive information. Check whether users can review, edit and undo AI-generated actions, and whether errors are explained in language that supports recovery. Evaluate representative tasks with disabled users where possible rather than relying only on automated checks or internal assumptions. Make sure important status changes are announced, focus is not lost and the interface does not require a single sensory channel. Record accessibility failures alongside other release-blocking defects, assign owners and retest after fixes. Accessibility is not a final polish layer; it is part of whether the feature works for the people it is meant to serve.
Founder analysis · Designing AI features for accessibility from day one - Ninth Post
What this means in practice
Accessibility testing should include people who use assistive technology, not only automated checkers. AI interfaces need understandable error messages, keyboard and screen-reader support, adjustable timing, clear control over generated changes, and alternatives when speech, vision, or text recognition fails. Evaluate the whole user journey, including review and correction—not just whether the model can produce an answer.
Sources and further reading
These references provide additional context for the frameworks discussed in this article. Check the source directly for its scope, date and limitations.
Related Ninth Post reading
- RAG vs fine-tuning: which approach does your AI product need?
- An AI data privacy checklist for product teams
- How to evaluate an AI feature before launch