AI Agents Don’t Live with Disabilities. People Do

Key Takeaways

• AI agents don’t automatically know what someone using a screen reader, switch device, or voice control needs.
• Research the partners with people with disabilities helps teams write clear, testable accessibility requirements before they build.
• Complete testing combines automated scans, keyboard and screen reader checks, and validation with real assistive technology users.

Teams everywhere are racing to deploy AI agents, and a common assumption comes along for the ride: that these agents are smart enough to handle accessibility right out of the box. They’re not, and the reason is clear: AI agents don’t live with a disability. People do. 

When we assume an agent already knows what a person using a screen reader, a switch device, or voice control actually needs from an interface, we create what we call the accessibility gap. A better model won’t solve the issue, but intentional design will. 

Here’s what we’ll cover:

Why AI can’t solve accessibility
Design AI experiences across dimensions of disability
Turn accessibility research into design requirements
Test accessibility at three levels
Gaps in accessibility are gaps in process

Why AI can’t solve accessibility

AI agents are trained on the web as it exists, and the web isn’t especially accessible. According to WebAIM’s 2026 report on the accessibility of the top 1,000,000 home pages, 95% of the top one million tested sites have at least one Web Content Accessibility Guidelines (WCAG) failure on their homepage alone. Automated testing tools, the ones most teams rely on to catch these issues, detect only about 30% to 40% of WCAG success criteria failures in the first place.

That gap shows up differently depending on how someone experiences an interface. Screen reader users lose track of dynamically generated content: without proper focus management or live regions, there’s no way to know whether the page actually did anything. People with motor disabilities face an interface that never stops moving, so a constantly shifting UI becomes an ever-moving target. People with cognitive disabilities get overwhelmed by agents that behave inconsistently from one moment to the next.

None of this means AI can’t build accessibly. It means we’ve got to tell it, explicitly, what “good” looks like. And it needs to be grounded in how real people actually work.

Back to top

Design AI experiences across dimensions of disability

To build with intentionality, we don’t start with prompt engineering. We start where good design has always started: with people. Our approach breaks down into three steps.

1. Extend your personas across disability dimensions

You likely already have personas. Extend them across three dimensions: 

• visual – screen reader users, low vision, color blindness
• motor – keyboard-only users, switch access, limited dexterity
• cognitive – users who need simpler layouts, fewer distractions, and predictable flows

Example: Take James, a program analyst at a federal agency who wants Agentforce to help him synthesize dense reports faster. As a baseline user, his frustration is generic: agentic content that lacks context and transparency about how the AI is using his instructions. 

Now extend James’ persona across the visual dimension: he’s been blind since birth, and he navigates with a screen reader and a Braille display. His goal doesn’t change, but his frustration sharpens considerably. When dynamic streaming text and field updates don’t reach his screen reader, or when the agent doesn’t manage focus properly, he has to reorient himself over and over. That’s not a minor annoyance. It’s the difference between finishing his work and getting stuck.

2. Define accessible jobs to be done 

A standard job to be done for James might read: “When analyzing a dense program report, I want Agentforce to synthesize findings and populate audit fields so I can complete my evaluation faster.” That’s a good start, but it has what we call an AI reality gap: it doesn’t account for what happens when James can’t perceive the update at all. 

The accessible version keeps his goal intact but names the real requirement: “I want my screen reader to be given concise summaries of what’s changed, know when updates happen, and keep my place, so I can verify findings and submit my evaluation faster without losing my orientation.” Same job. Sharper, more honest definition of what success requires.

3. Test with real assistive technology users, not simulations 

Putting on a blindfold or setting your mouse aside for an afternoon won’t give you the lived experience of someone who uses assistive technology every day. Automated tools and compliance checklists miss the real-world friction that shows up only in practice. Recruit participants who live with these disabilities, partner with local disability advocacy groups, and compensate people fairly. They’re subject matter experts, and that’s how they should be treated.

Back to top

Turn accessibility research into design requirements

Once you’ve combined an extended persona with an accessible job to be done, you can write inclusive acceptance criteria: typically three-to-five binary pass or fail statements, at least one of which covers an edge case, structured as: 

Given [a person in context]

When [an action is taken]

Then [an expected outcome occurs].

For example:

• Screen reader users: Given a VoiceOver user navigating a dynamic Agentforce task update, when the AI finishes generating a response, then a live region informs the user that a response is available.
• Keyboard-only users: Given a keyboard-only user navigating an Agentforce workflow, when action items appear in the agent’s response, then all actions are reachable within standard tab order with touch targets of at least 44×44 pixels.

Feed these criteria directly into your prompts and pair them with an explicit request for Salesforce Lightning Design System 2 guardrails. That combination ensures the model includes accessibility parameters because you told it to, not because you’re hoping it inferred them correctly. 

AI can accelerate the build. It can write the code. What it can’t do is be the human at the helm. That part is still on us.

Back to top

Test accessibility at three levels

Automated testing tools are your baseline, not your ceiling. They’re excellent at catching syntax errors and contrast issues before code ships, but remember, they test only 30% to 40% of the WCAG success criteria failures that exist. A complete testing approach has three layers:

1. Automated scans to catch what’s mechanically detectable early. 
2. Manual testing with a keyboard and screen reader to confirm every actionable element is reachable and understandable. 
3. User validation with the same research group you started with, checking whether the build actually meets the acceptance criteria you wrote. If it doesn’t, feed that back into the prompt and let the AI try again.

Back to top

Gaps in accessibility are gaps in process

Here’s the throughline: the accessibility gap isn’t a failure of AI technology. It’s a gap in process. Start with user research. Use authentic, extended personas. Write accessibility-focused acceptance criteria before you build. Then build. Then test. 

Designing this way doesn’t just support people with disabilities – it creates a smoother, more intuitive experience for everyone.

Back to top