Case studies
Concrete cases are the fastest way to see the patterns in this site play out. Each entry below is a real situation, what happened, and what it shows. They are grouped by whether the AI product failed disabled users, helped them, or was used to build and check accessibility.
Key points
Section titled “Key points”- These are real cases showing the site’s patterns in practice, grouped by AI failing disabled users, helping them, or building accessibility.
- When AI fails, the organization still owns what it says, and small markup choices like fake links can be total blockers.
- AI genuinely helps too, letting disabled people build their own tools, but it does not excuse an inaccessible product underneath.
- AI-assisted remediation and audits work only with a person in the loop, since automated fixes often introduce or miss issues.
- Many of these cases exist because a disabled person documented exactly what failed, which is what made them actionable.
When AI products failed disabled users
Section titled “When AI products failed disabled users”The Air Canada chatbot gave a customer wrong information about a fare, and a tribunal held the airline responsible, rejecting the argument that the chatbot was a separate party. It shows that an organization owns whatever its AI says, and that a confident wrong answer has real consequences. This informs Uncertainty and confidence and Agentic actions.
Download links that were not links locked a blind user out of files an AI tool had generated, because the downloads were rendered as plain text rather than focusable links. A small markup choice became a total blocker. This informs WCAG Operable, Generated content, and Agentic actions.
Disability bias in language models showed up when Penn State researchers found sentiment and toxicity tools scored statements about disability as more negative and toxic, with the word “blind” flagged regardless of meaning. It shows the bias is in the model, not the context. This informs Bias and representation.
When AI helped disabled people
Section titled “When AI helped disabled people”Building your own assistive tool is what Blake Watson did, using an AI coding assistant to make a native scrolling tool for his own mobility needs. It shows AI lowering the barrier to creating assistive technology from a plain description of what you need. This informs Why it matters and What is AI accessibility?.
AI as a daily helper, with caveats is how one blind user describes Copilot speeding up screen-reader-heavy tasks, while the host application’s own accessibility lagged behind. It shows that AI as a helper is real and useful, and that it does not excuse an inaccessible product underneath. This informs What is AI accessibility?.
When AI was used to build, fix, or audit
Section titled “When AI was used to build, fix, or audit”Fixing ChatGPT’s interface with ChatGPT is what an auditor did when the prompt field and send button had no accessible label, getting a working fix in minutes but needing human steering to avoid over-using ARIA. It shows AI-assisted remediation works with a person in the loop. This informs Testing methodology and WCAG Robust.
A “100 percent accessible” AI-built site fell short when it was tested with a real screen reader user, despite the marketing claim. It shows that generated accessibility claims need real testing before you trust them. This informs User testing and Generated content.
AI remediation at scale was measured by Karl Groves, who tested 79 fixes drawn from real errors and found problems in 52 percent of them. It shows the automation ceiling applies to fixing issues, not just finding them. This informs Automated tools.
AI as a workaround, not a fix is shown by a blind worker using an AI tool to drive an otherwise inoperable Salesforce interface. It shows AI can bridge a gap, and it can also let a vendor avoid building real accessibility into the product. This informs Agentic actions.
Google’s AI coding tool failed its own demo prompt is what Adrian Roselli found when he gave Google’s Modern Web Guidance the accordion prompt from its own homepage. The generated component was not WCAG conformant, ignored the ARIA Authoring Practices Guide accordion pattern, and broke in Firefox. It shows that a vendor’s accessibility promise for generated code does not survive its own example, so a vetted pattern library beats trusting the tool. This informs Generated content and Output auditing.
Audience: Product Manager
Read the failures as risk, not trivia. The Air Canada case is a liability the organization could not disclaim, and the “100 percent accessible” claim is the reputational trap of trusting a tool’s own marketing. The throughline is that AI output is your product’s output, so the cheapest insurance is the testing loop and a real path for users to report problems.
Audience: Self-advocate
Several of these cases exist because a disabled person documented exactly what failed and why it mattered, which is what made them actionable. If a tool fails you in one of these ways, a specific account, naming the assistive technology and the precise breakdown, is the kind of report that changes products and sometimes sets precedent.