The Cost of Accessibility in AI

Jemima Abu, CAIS10:02 · Oct 2026 · 248 views
Thumbnail for The Cost of Accessibility in AI Watch on YouTube
TL;DR
  1. 1

    An accessibility skill reduced the cost of one Figma implementation run by 58% and reduced its completion time to about a third, although the experiment cannot prove that accessible development is always cheaper.

  2. 2

    AI agents copy the conventions of their codebase and often replace native HTML with verbose custom components that require more implementation and testing.

  3. 3

    Accessibility needs to be specified from business requirements through QA, with semantic HTML, keyboard support, reusable components, audits, agent guidance, and manual review.

Summary

Jemima Abu argues that accessibility should be part of how AI-generated products are specified and built, rather than a repair step after implementation. In her small experiment, the same Figma prompt ran once without accessibility guidance and once with an accessibility skill. The guided run cost 58% less and finished in about a third of the time, but Abu is clear that this uncontrolled comparison cannot prove a general cost advantage. She attributes the difference partly to the agent's tendency to write verbose custom components instead of using native HTML. Recreating semantics, keyboard behavior, and browser features creates extra code and testing. Abu recommends auditing the existing codebase, defining platform-specific requirements, using reusable components, and giving agents explicit accessibility skills. Semantic HTML should come before ARIA, interactive controls should work with keyboards, and automated checks should be followed by human testing. The talk also covers business, legal, and refactoring costs when accessibility is postponed.

Key ideas
00:00

Accessibility is part of whether an AI-generated product is usable

Abu defines accessibility as the ability to use a product regardless of disability. She connects the issue to AI-generated interfaces, where teams can produce several applications quickly while leaving people unable to use them. She cites a WebAIM study reporting that 96% of the homepages among the top 1 million websites had some accessibility issue. Her argument is that AI-generated code still needs to be built for humans, rather than accepted because it runs for the developer who created it.

01:14

One experiment found lower cost with accessibility guidance, but it is not proof

Abu used a work codebase and gave an agent the same prompt twice: implement a Figma design. The first run had no accessibility skill, and the second used a skill she had written. The guided run showed a 58% cost reduction and took about a third of the time. She immediately limits the claim. It was a one-off comparison in an uncontrolled environment, so it cannot establish that AI agents always build accessible websites more cheaply. The result does show that guidance can change how much work the agent does.

03:42

Agents inherit the biases and conventions of their codebase

Abu says an agent is impressionable and learns from the context given to it. A codebase built around an 'it works for me' attitude can teach the agent that screen readers, low-light use, and other access needs do not matter. The agent then repeats those assumptions in new code. Over time, generated code can make the codebase more inaccessible because accessibility was never made a constraint. Clear prompts and skills give the agent a better path through the existing system.

04:21

Native HTML avoids much of the work in custom components

Without guidance, Abu says AI tends to reinvent components instead of checking whether a semantic HTML element already provides the needed behavior. A custom accordion or modal may require the agent to recreate semantics, keyboard interaction, browser behavior, and other features. That brings more code and more testing. Her recommendation is to direct agents toward semantic elements and newer HTML and CSS features before asking them to implement custom JavaScript versions.

05:21

Accessibility has to enter at the business and design stages

Abu compares accessibility to blueberries baked into a muffin. Adding ARIA labels after a site is complete does not fix decisions made earlier in the process. Accessibility belongs to the business idea, design, development, and QA work. Waiting until the end leads to refactoring, rewritten code, and regression testing. She also rejects the claim that a product need not support assistive technology because its current users do not use it. People who cannot use the product may never become users.

06:06

Inaccessible products create business and legal costs

Abu points to lost customers, extra implementation and refactoring time, and possible legal consequences. She describes the absence of accessibility as an access problem: if people cannot get into the product, they will not use it. She also mentions the Americans with Disabilities Act and says public-facing products can face fines and lawsuits when they are not accessible. These costs add to the engineering work created when accessibility is postponed.

07:30

Teams should prepare the codebase before adding an agent

Abu recommends defining the accessibility requirements for the target platform, then auditing the existing codebase for issues that an agent might copy. Automated tools can help, and an agent can be asked to perform an audit, but existing problems should be fixed before new features are generated. Reusable components or a design system reduce repeated fixes because one corrected component can be used in many places.

08:44

Agent skills can encode baseline accessibility checks

Abu recommends a mandatory accessibility skill for tasks that generate UI or write related code. She mentions Chrome's Modern Web Guidance skill, which encourages current HTML and CSS features instead of custom JavaScript implementations. A lighter skill can give smaller projects a short checklist: use semantic HTML, use ARIA only when native HTML cannot express the behavior, support keyboard operation, label elements for screen readers, and audit the result before running it. These checks do not replace manual testing, because no single tool can make a site fully accessible.

"We need to ensure that even with all the code being written by AI, we're still building for humans, and we're ensuring that humans are able to use the products that we are building."00:16
Who should watch
  • You are using coding agents to generate interfaces and need concrete instructions that reduce inaccessible defaults.
  • Your existing codebase has inconsistent accessibility patterns and you want to prepare it before asking an agent to add features.
  • You are deciding whether accessibility belongs in product, design, implementation, and QA work, rather than in a final cleanup pass.