Salesforce Says AI Agents Cannot Infer Accessibility on Their Own

Executive Summary

• Salesforce argues that AI agents do not arrive with built-in accessibility knowledge, so teams that assume an agent will handle screen readers, switch devices or voice control correctly create an accessibility gap. Salesforce Blog
• Salesforce cites WebAIM's 2026 report on the top 1,000,000 home pages, which found 95% of tested sites have at least one WCAG failure on the homepage alone. Salesforce Blog
• Automated testing tools detect only about 30% to 40% of WCAG success criteria failures, according to the post, which is why Salesforce recommends three testing layers: automated scans, manual keyboard and screen reader checks, and validation with real assistive technology users. Salesforce Blog
• Salesforce recommends writing three to five binary pass or fail acceptance criteria, at least one covering an edge case, in Given/When/Then form and feeding them into prompts alongside explicit Lightning Design System 2 guardrails. Salesforce Blog

Key Takeaways

• Salesforce frames the accessibility gap as a process failure rather than a technology failure, arguing that a better model will not resolve it but intentional design will.
• The company's method extends existing user personas across visual, motor and cognitive dimensions of disability before any prompt is written.
• Accessible jobs-to-be-done restate a user's goal while naming the precise requirement, such as screen reader summaries, update notifications and preserved focus position.
• Salesforce positions people with disabilities as subject matter experts who should be recruited, partnered with through local advocacy groups and compensated fairly, rather than simulated through blindfolds or mouse-free afternoons.

Salesforce on Why Agents Cannot Infer Accessibility

The central claim in the post is blunt: AI agents are trained on the web as it exists, and the web is not especially accessible. Salesforce points to WebAIM's 2026 report on the accessibility of the top 1,000,000 home pages, which recorded that 95% of the top one million tested sites have at least one Web Content Accessibility Guidelines failure on their homepage alone. An agent learning from that corpus inherits the same omissions it is being asked to fix.

The failure modes differ by disability dimension. Screen reader users lose track of dynamically generated content when focus management or live regions are missing, leaving no signal that the page responded. People with motor disabilities contend with interfaces that never stop moving, making a constantly shifting UI an ever-moving target. People with cognitive disabilities face agents that behave inconsistently from one moment to the next. Salesforce's conclusion is not that AI cannot build accessibly, but that teams must state explicitly what good looks like, grounded in how real people work.

The post also flags the limits of the tooling most teams lean on. Automated testing tools detect only about 30% to 40% of WCAG success criteria failures, which means a passing scan is a floor rather than a clearance.

Salesforce Three-Step Method for Disability-Inclusive Design

Salesforce's approach starts with people, not prompt engineering, and breaks into three steps.

First, extend existing personas across visual, motor and cognitive dimensions. The post uses James, a program analyst at a federal agency who wants Agentforce to synthesize dense reports faster. As a baseline user his frustration is generic. Extended across the visual dimension, he has been blind since birth and navigates with a screen reader and a Braille display. His goal does not change, but his frustration sharpens: when dynamic streaming text and field updates do not reach his screen reader, or the agent does not manage focus properly, he has to reorient repeatedly.

Second, define accessible jobs to be done. A standard version might read that when analyzing a dense program report, James wants Agentforce to synthesize findings and populate audit fields so he can finish his evaluation faster. Salesforce calls this an AI reality gap because it does not account for what happens when James cannot perceive the update at all. The accessible version keeps the goal intact but names the requirement: screen reader summaries of what changed, notification when updates happen, and preserved position so he can verify findings and submit without losing orientation.

Related: Salesforce Ties Openai Reasoning to Agentforce Workflows in 2026

Third, test with real assistive technology users rather than simulations. Salesforce states directly that wearing a blindfold or setting a mouse aside for an afternoon does not reproduce the lived experience of daily assistive technology use. It recommends recruiting participants who live with these disabilities, partnering with local disability advocacy groups and compensating people fairly, treating them as subject matter experts.

Salesforce Guidance on Acceptance Criteria and Testing Layers

Once a persona is extended and an accessible job to be done is defined, Salesforce 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.

For deeper context, see our Investments analysis: "Reduciner Raises €3.6M in 2026: Finnish CO2-to-Fuel Startup Targets Cement".

The criteria are meant to go directly into prompts, paired with an explicit request for Salesforce Lightning Design System 2 guardrails. Salesforce's stated rationale is that this ensures the model includes accessibility parameters because you told it to, not because you hoped it inferred them correctly.

Testing then 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 screen reader confirms every actionable element is reachable and understandable. User validation with the original 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.

Salesforce Signals Table

The source does not name specific customers, regions, revenue figures or deployment timelines beyond the persona illustration, so no additional rows are included.

Additional coverage: Tech Giants Form AI Safety Alliance to Standardize Security in 2026

Salesforce Implementation Risks

Salesforce identifies the principal risk as treating accessibility as a tooling problem. Automated scans are useful but detect only about 30% to 40% of WCAG success criteria failures, so a clean scan can coexist with real barriers. A second risk is simulation-based testing, which the post says cannot substitute for participants who use assistive technology daily. Documented friction points include dynamically generated content that never reaches a screen reader without focus management or live regions, continuously moving interfaces for people with motor disabilities, and inconsistent agent behavior for people with cognitive disabilities. Salesforce also warns against assuming an agent inferred accessibility parameters on its own rather than being told.

Editorial independence disclosure: this analysis is based solely on the sourced post and does not reflect any relationship with the company named. Source note: all facts above derive from Salesforce Blog.

What This Means for Practitioners

For teams buying or building agentic workflows, the practical shift is procedural rather than technological. Accessibility requirements need to exist before prompt design, expressed as binary, testable acceptance criteria that can be embedded in prompts and checked after generation. Budget should cover recruitment of assistive technology users and the manual keyboard and screen reader passes that automated scans cannot replace, since scans catch under half of WCAG success criteria failures. Procurement teams evaluating agent platforms should ask whether vendors supply accessibility-specific acceptance criteria and design system guardrails, or leave teams to infer them. The post's core claim applies directly to that decision: the model will not supply what the process never specified.