AI Agents Learned Accessibility From the Web. The Web Is Not Accessible.

Every enterprise is racing to deploy AI agents, and a common assumption comes along for the ride: that the agent will handle accessibility on its own. This week, Salesforce published a design guide with a blunt rebuttal. AI agents are not accessible out of the box, the company argues, and the reason is structural: they are trained on the web as it exists, and the web is not especially accessible.

The guide, published on the Salesforce blog, introduces the idea of an accessibility gap: the distance between what a team assumes an agent knows and what a person using a screen reader, a switch device, or voice control actually needs. Its central claim is that this gap is a process failure, not a technology failure. A better model will not close it. Explicit, intentional design will.

The gap by the numbers

Salesforce grounds the argument in the WebAIM 2026 report on the accessibility of the top one million home pages. According to the post, 95% of those sites have at least one Web Content Accessibility Guidelines failure on the homepage alone. An agent trained on that corpus learns what the web does, not what accessible design standards say it should do. It reproduces the same omissions it was trained on.

The failure modes differ by disability dimension. People who use screen readers lose track of dynamically generated content: without proper focus management or live regions, there is no signal that the page responded at all. People with motor disabilities contend with interfaces that never stop moving, which turns a constantly shifting UI into 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 cannot build accessibly, the post argues. It means teams must state explicitly what good looks like, grounded in how real people work.

The post also challenges the tooling most teams lean on. Automated accessibility testing tools detect only about 30% to 40% of WCAG success criteria failures, according to the guide. A passing scan is therefore a floor, not a clearance, and leaves most real barriers undetected.

Start with people, not prompts

The method Salesforce recommends has three steps, and the first two happen before any prompt engineering. Step one is to extend existing user personas across three disability dimensions: visual (screen reader users, low vision, color blindness), motor (keyboard-only users, switch access, limited dexterity), and cognitive (users who need simpler layouts, fewer distractions, and predictable flows).

The guide illustrates this with James, a program analyst at a federal agency who wants Agentforce to help him synthesize dense reports faster. As a baseline persona, his frustration is generic: agentic content that lacks context and transparency about how the AI uses his instructions. Extended across the visual dimension, James is blind and navigates 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 post is explicit about the stakes: that is not a minor annoyance, it is the difference between finishing his work and getting stuck.

Step two is to define accessible jobs to be done. A standard job 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. Salesforce calls what is missing the AI reality gap, because it does not account for what happens when the user cannot perceive the update at all. The accessible version keeps the goal intact but names the real requirement: the screen reader should announce concise summaries of what changed, the user should know when updates happen, and the interface should keep his place so he can verify findings and submit without losing orientation. Same job, sharper and more honest about what success requires.

Turn research into requirements

Once a persona is extended and an accessible job to be done is defined, the guide says teams can write inclusive acceptance criteria: typically three to five binary pass or fail statements, at least one covering an edge case, structured as Given a person in context, When an action is taken, Then an expected outcome occurs.

The post supplies two examples. 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 by 44 pixels. The criteria go directly into prompts, paired with an explicit request for Salesforce Lightning Design System 2 guardrails. The rationale is that the model includes accessibility parameters because you told it to, not because you hoped it inferred them correctly.

Test with experts, not simulations

Step three is where the guide takes its strongest position. Putting on a blindfold or setting a mouse aside for an afternoon will not give anyone the lived experience of someone who uses assistive technology every day, the post states. Instead, teams should recruit participants who live with these disabilities, partner with local disability advocacy groups, and compensate people fairly.

They are subject matter experts, and that is how they should be treated.

Testing itself runs at three levels. Automated scans catch what is mechanically detectable early, such as syntax errors and contrast issues before code ships. Manual testing with a keyboard and a screen reader confirms every actionable element is reachable and understandable. User validation with the same research group checks whether the build actually meets the acceptance criteria. If it does not, Salesforce says to feed the result back into the prompt and let the AI try again.

Why this matters now

The timing is notable. At an FCC event this week accompanying the release of the agency's 2026 CVAA report, regulators found continued progress in access to advanced communications services but said some accessibility gaps persist, with concerns raised about mobile phones, videoconferencing, emergency services, multifactor authentication, AI products, customer service, and communications in video games. The panelists making the case were people with disabilities themselves, including Gallaudet University's Technology Access Program director, who described using AI translation apps to converse with people who do not sign, and the American Council of the Blind's advocacy director, who described navigating the subway with smart glasses and reading her mail with phone apps.

That is the deeper point of Salesforce's guide. The accessibility gap in AI agents is not a niche edge case; it sits at the center of how an entire generation of workplace software will be operated. AI can accelerate the build and write the code, but as the post puts it, it cannot be the human at the helm. Designing agentic interfaces that work for everyone starts with treating the people who know accessibility best as experts from day one, not as a compliance check at the end.