According to an article discussing the deployment of artificial intelligence agents, teams everywhere are racing to deploy these agents, accompanied by a common assumption that the agents are smart enough to handle accessibility right out of the box. The article states that this assumption is incorrect, and the reason is clear: AI agents do not live with a disability, while people do. When teams assume that an agent already knows what a person using a screen reader, a switch device, or voice control actually needs from an interface, it creates what the authors call the "accessibility gap." A better model will not solve this problem, but intentional design will.
Why AI Cannot Solve Accessibility by Itself
According to the article, AI agents are trained on the web as it exists today, and the existing web is not especially accessible. According to a 2026 report by WebAIM 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. In addition, automated testing tools, which are the tools most teams rely on to catch these issues, detect only about 30% to 40% of WCAG success criteria failures in the first place.
This gap shows up differently depending on how a person experiences an interface. Screen reader users lose track of dynamically generated content: without proper focus management or live regions, they have no way of knowing whether the page did anything at all. People with motor disabilities face an interface that never stops moving, so a constantly shifting user interface becomes an ever-moving target. Likewise, people with cognitive disabilities experience overwhelm from agents that behave inconsistently from one moment to the next.
The article clarifies that this does not mean AI is incapable of building accessibly. It means that it must be explicitly defined what good looks like, and this definition must be grounded in how real people actually work.
Designing AI Experiences Across Dimensions of Disability
To build with intentionality, the approach presented in the article does not start with prompt engineering, but starts where good design has always started: with people. The approach breaks down into three central steps:
The first step is extending existing personas across different disability dimensions. According to the article, you likely already have personas, and they should be extended across three dimensions: the visual dimension (screen reader users, low vision, and color blindness); the motor dimension (keyboard-only users, switch access, and limited dexterity); and the cognitive dimension (users who need simpler layouts, fewer distractions, and predictable flows).
As an example, the article presents 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 lacking context and transparency regarding how the AI uses his instructions. When extending James's persona across the visual dimension—being blind since birth and navigating with a screen reader and a Braille display—his goal does not change, but his frustration sharpens considerably. When dynamic streaming text and field updates do not reach his screen reader, or when the agent does not manage focus properly, he has to reorient himself over and over. The article notes that this is not a minor annoyance, but the difference between finishing his work and getting stuck.
The second step is defining accessible Jobs to be Done. A standard job to be done for James might be phrased as: "When analyzing a dense program report, I want Agentforce to synthesize findings and populate audit fields so I can complete my evaluation faster." According to the article, this is a good start, but it contains what is termed an AI reality gap, as it does not account for what happens when James cannot perceive the update that occurred at all. The accessible version preserves his original goal while stating 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." The article emphasizes that this is the same job, but with a sharper and more honest definition of what success requires.
The third step is testing with real assistive technology users, rather than simulations. Putting on a blindfold or setting the mouse aside for an afternoon will not provide the lived experience of someone who uses assistive technology every day. Automated tools and compliance checklists miss the real-world friction that appears only in practice. The article recommends recruiting participants who live with these disabilities, partnering with local disability advocacy groups, and compensating participants fairly, as they are subject matter experts and should be treated as such.
Translating Accessibility Research into Design Requirements in Prompts
After combining an extended persona with an accessible job to be done, inclusive acceptance criteria can be written. These criteria typically include three to five binary pass or fail statements, with at least one covering an edge case. Their structure is defined as: Given [a person in context], When [an action is taken], Then [an expected outcome occurs].
The article provides examples of these criteria: For 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. For 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.
These criteria should be fed directly into prompts and paired with an explicit request for guardrails from the Salesforce Lightning Design System 2. This combination ensures that the model includes accessibility parameters because it was explicitly told to do so, rather than out of hope that it would infer them correctly on its own. AI can accelerate the build and write the code, but what it cannot do is be the human at the helm, and that role remains on us.
Testing Accessibility at Three Complementary Levels
According to the article, automated testing tools are the baseline and not the ceiling. These tools excel at catching syntax errors and contrast issues before code ships, but they test only 30% to 40% of the WCAG success criteria failures that actually exist. Therefore, a complete testing approach includes three layers:
- Automated scans to catch what is mechanically detectable early.
- Manual testing with a keyboard and screen reader to confirm that every actionable element is reachable and understandable.
- User validation with the same research group with which the process started, to check whether the built product actually meets the written acceptance criteria. If it does not meet them, feed the findings back into the prompt and let the AI try again.
Accessibility Gaps as Process Gaps
The guiding throughline of the article is that the accessibility gap is not a failure of AI technology, but a gap in process. Teams must start with user research, use authentic and extended personas, and write accessibility-focused acceptance criteria before the build phase. Only then should they build and test. The article concludes that designing in this way does not just support people with disabilities, but creates a smoother and more intuitive experience for everyone.