The Cost of Accessibility in AI — Jemima Abu, CAIS
Read the talk
The Cost of Accessibility in AI
Jemima Abu connects a small Figma implementation experiment to a larger engineering cost: agents can spend time rebuilding browser behavior, copying inaccessible conventions and creating repairs that better requirements would avoid.
From a talk by Jemima Abu
At a glance
Ideas worth remembering
One uncontrolled Figma implementation experiment reported 58% lower cost and about a third of the completion time with an accessibility skill; it does not establish a general cost advantage.
An agent can copy inaccessible repository conventions. Audit and repair existing patterns before using them as the starting point for new features.
Native HTML can avoid custom implementation and testing work. Explicitly ask the agent to consider semantic elements before recreating their behavior.
Accessibility skills should cover semantics, keyboard operation, labels and an audit, while retaining manual testing of the finished experience.
The same design prompt, with different guidance
“Stop wasting tokens on building products that people can't use.” That is Jemima Abu’s opening formulation of the cost of accessibility in AI. A product that an agent generates quickly still has to work for humans, including people with disabilities. Abu, a product engineer at CAIS, starts with a familiar objection to accessibility work: “It takes too long.” Her experiment asks whether leaving it out can itself waste development time.
The input was deliberately simple: implement a design from Figma in the codebase at work. Abu ran the prompt twice, first without an accessibility skill and then with one she had written. How did the runs compare? With the skill, the reported cost fell by 58%, and completion took about a third of the time. These are results from one uncontrolled experiment, not evidence that accessible development always costs less. Abu immediately withdraws that tempting generalization: “We can say that, but we won't say that.”
The useful question becomes what the unguided agent spent its effort doing. A timing comparison alone cannot establish the cause of the difference. Examining the implementation choices can still expose avoidable work—and suggest instructions that make the next attempt less likely to repeat it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The codebase teaches the agent what counts as finished
Abu uses the Netflix show Old Enough to explain why guidance matters. Toddlers undertake their first errands, but their parents have prepared the conditions: familiar trips to the shop, a detailed list, directions and paths to avoid. The analogy is about preparation. “Build this webpage” leaves decisions open; useful instructions narrow the routes an agent can take toward the intended result.
The surrounding code also supplies guidance, even when nobody writes it as a requirement. A developer may stop at “it works for me,” without checking screen-reader use or low-light conditions. If those omissions recur throughout a repository, an agent can reproduce them as local conventions. Accessibility never appears as a constraint, so new generated features continue to omit it.
That creates a compounding problem: each generated implementation becomes another example for subsequent work. An inaccessible codebase supplies inaccessible patterns, and repeated generation adds more of them. Explicit prompts matter, but so does correcting the examples the agent is likely to follow.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Custom code can recreate work the browser already does
The concrete failure Abu noticed in the experiment was verbose implementation. Asked for an accordion or modal, an unguided agent can start building from scratch without first considering whether an existing semantic HTML element provides the required functionality. “AI loves to write code.” The cost arrives when that code takes responsibility for behavior a native element could already supply.
What extra work does the custom implementation create? Recreating a semantic element requires implementing its native features and testing the replacement. The comparison is between two starting points: browser-provided behavior that the application can use, and application code that must reproduce that behavior. More generated code brings more behavior to verify. That is a plausible source of wasted effort in this example, rather than a reason to equate code volume with progress.
The prompt should therefore influence the implementation choice before the agent commits to a custom component. Later in the talk, Abu makes the rule explicit: use semantic HTML wherever possible, and reach for ARIA when semantic HTML cannot express the behavior. The decision starts with what the interface must do, then asks how much of that the platform already supports.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Accessibility added at the end creates a second implementation pass
The blueberry muffin analogy gives this timing problem a memorable shape. Blueberries pushed onto a finished plain muffin do not make the same thing as blueberries baked into it. Similarly, adding ARIA labels around a completed website does not by itself make the website accessible. Labels cannot substitute for considering accessibility throughout the business idea, design, implementation and QA.
Waiting changes the work required. Once a product is complete, accessibility testing can reveal decisions that require refactoring or rewriting existing code. Those changes then require regression testing: the team has to check the repaired behavior and check that the changes have not broken other behavior. Earlier requirements can avoid some of that second pass by shaping the original implementation.
There are also costs outside the engineering task:
- Excluded customers. “None of our users rely on assistive technologies” can be a self-fulfilling observation. People who cannot use the product may never become users. Abu compares it to a business without a door: the absence of customers does not establish an absence of demand.
- Legal exposure. Abu points to the Americans with Disabilities Act and the possibility of lawsuits and fines. Her discussion is a broad warning about inaccessible public-facing products, rather than a determination of any particular product’s legal obligations.
The cost calculation therefore extends beyond the agent’s bill. It includes custom behavior to implement, repairs to make, regressions to check and people the product prevents from participating. These are the mechanisms behind Abu’s recommendation to begin with accessibility, even though her two-run experiment cannot quantify their general savings.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Define requirements, repair examples and reuse the fixes
The practical sequence begins with platform-specific requirements. Web, mobile and hardware do not present identical accessibility work, so the team first needs to establish what the product must support. An agent cannot reliably satisfy requirements that the team has left unstated.
Next comes an audit of the existing codebase. Automated accessibility tools—or an agent asked to inspect the code—can help identify issues. The important correction is to fix those issues before generating new features around them. This interrupts the earlier failure mode in which existing defects become examples of acceptable implementation.
A reusable component library or design system makes subsequent corrections cheaper to apply. If several pages use one component, a fix belongs in that shared implementation. If each page contains its own copy, the same repair has to be repeated across files. Abu presents reuse as a useful aid, rather than a prerequisite for every project.
Finally, make an accessibility skill mandatory whenever the agent generates relevant UI or code. Abu mentions Chrome’s Modern Web Guidance skill as one she likes for encouraging newer HTML and CSS features instead of custom JavaScript implementations. A smaller project can use a lightweight set of instructions; the goal is to make the desired choices available during generation without requiring extensive research for every task.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A minimum accessibility skill still needs human testing
Abu’s lightweight skill gives the agent concrete criteria to apply:
- Semantic HTML first. Use native elements wherever possible; use ARIA when native semantics cannot express the required behavior.
- Keyboard operation. Any interactive element that works with a mouse should also work with a keyboard.
- Readable labels. Label elements properly so screen readers can read them.
- An agent audit. Before running the code, check the implementation against those instructions.
This is a minimum starting point, not a complete accessibility assessment. An agent’s audit can check whether it followed the stated rules, but no single tool can make the finished website fully accessible. Manual testing remains necessary. The skill improves the instructions and implementation patterns; people still have to evaluate the resulting experience.
The closing criterion returns to the purpose of building anything with AI: solve a problem in a way that people can use. Faster generation is useful when it produces a useful solution. Accessibility requirements help keep that goal present while the agent chooses components, writes code and checks its work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Related talks
- Beating RL With Reflection: GEPA and Optimize Anything
Develops the complementary question of how repository skills can be learned from agent attempts and reused to reduce repeated discovery and improve later work.
Read the complete timestamped transcript
- 0:00
Hiya, my name is Jemima, and I'm going to be talking to you about the cost of accessibility in AI, or as I like to call it, stop wasting tokens on building products that people can't use. Because at the end of the day, what is accessibility? Accessibility is the quality of being able to be used by anyone, regardless of disability. So what this means is that when you build a product that is inaccessible, that product is inherently useless because people cannot use it. I think this is a very prevalent talk, especially in these days of vibe coding and prompt engineering and AI basically writing all the code for us. We need to
- 0:30
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. It's all very well and good to vibe code five different apps in one day, but if people can't use those apps, then is there really any point? A study by WebAIM shows that ninety-six percent of the homepages of the top one million websites in the world have some form of accessibility issue or another. Now, I'm someone that goes around a lot and speaks about accessibility. And whenever I ask, "Why don't people build websites to be accessible?" I usually hear, "It takes too long." While I will
- 1:00
agree that accessibility is a labor and time-intensive process, I do think that now that we're getting to the stage of AI writing most of our code, it's actually easier to make things accessible. If anything, I would say it costs more time and more money to build inaccessible websites. So I decided to carry out a little experiment using the code base at work. So I gave this prompt to the agent. It's just a simple prompt with no guidelines, implement this design from Figma. And I ran it twice, the first time without any accessibility skill and the second time by using the skill that I had written. And what I noticed was that not only was it faster for the
- 1:30
agent to build the accessible skill, but there was also a fifty-eight percent reduction in cost when using that skill. And we can take a look at the data here. We see that not only was it cheaper, but it also took a third of the time to finish the prompt while using the accessibility skill. So in conclusion, we can say that it is actually cheaper for AI agents to build accessible websites. We can say that, but we won't say that because this was a one-off experiment and it was not carried out in a constrained environment, so it cannot serve as empirical data that proves the fact. But when we look into the reasons why it took the AI agent much longer to carry out the
- 2:00
prompt without any accessibility skills, then we can have a better idea of why exactly it is faster to build accessible websites. But before we get into that, hi, my name is Jemima Abu. I am a product engineer at CAIS, an alternative investment platform. I'm also a Google Dev Expert, a Microsoft MVP, and a certified professional in accessibility core competencies. Basically, I like to go around talking about how to make the web a more accessible place. Also, I will give a slight disclaimer. While a lot of my examples relating to accessibility will be web-based because that is my area of expertise, this can also apply regardless of whatever
- 2:29
platform you're working on, whether that's mobile or hardware or anything at all. So let's get back to it. This is your AI agent. Now, it's a super intelligent tool that can do almost anything in the world, but at the same time, it's just three years old. And much like a baby, AI is very impressionable. If you tell it enough times that the sky is red, eventually it'll start to accept that the sky is red. What this means is, as the responsible developers in charge, we have to make sure that we're providing the right skills and guidance for AI agents to build the product that we want them to build. There's a Japanese show on
- 2:59
Netflix that I love called Old Enough. It's basically about toddlers being sent on their first errand. It can be like a three-year-old being sent to a supermarket to purchase groceries. And one thing I like about the show is that you can always see the steps that the parents have put in place before they send them on that first errand. So it might be that the child has gone with their parents to this market multiple times, or they provide a list that is very clearly detailed. It shows them where the supermarket is, what they need to get there, what paths to avoid, and it basically makes it a lot easier for the child to carry out that errand. It's the same thing with an agent. When you are giving an instruction to an agent, if
- 3:29
I'm saying build this webpage or implement this design, if I provide the right skills and prompts, it makes it a lot easier for that agent to avoid going down the wrong path and for the finished product to look like what I intended it to look like. So let's take a look at what happens when we don't provide any form of guidance for our agents in developing products. Firstly, human bias becomes AI bias. For years, humans have been developing websites or products that are inaccessible because frankly, we just don't think that way. Especially as developers, we tend to have a it works for me mindset. So I'm like, "This thing works on my laptop and it works the way I
- 3:59
intended it to work and I'm not going to check anything else." I don't concern myself with if it works for screen readers or if it works in low-light environments. I'm just like, "It works, it's built, I'm done." Whenever you build like that or if you have a code base that reflects that kind of mentality, once you put an AI agent in that code base, it's going to absorb all your biases. It's going to say, "Oh, we don't need to make these things accessible because that has never been mentioned in the past, so I'm just going to build things anyhow." And then the more you use that AI agent to generate codes, the more you build a code base that is inherently inaccessible because accessibility was never a
- 4:29
constraint in the first place. Secondly, and this is something that I really noticed in the experiment, AI tends to default to a lot of verbose code. If you don't provide any particular prompts or guidelines for your agent, it will reinvent the wheel as many times as it wants to. So even if you tell it just build a simple accordion component or build a modal component, it's not going to bother checking is there already an existing semantic elements that can give me the same functionality? It's just going to build one from scratch. AI loves to write code. So it'll go off and write as many things as it wants. And as you can see
- 4:59
here, if you are trying to recreate a semantic element, it takes a lot more time and effort because number one, you have to carry out a lot more testing. You have to implement a lot more features to replicate the native functionality, and it's just a very cumbersome process. So this is part of the things that you want to ensure you're focusing on when you're providing prompts to your agent. I saw an analogy once that said an accessible website is like a blueberry muffin. If someone hands you a plain muffin that they've shoved a bunch of blueberries on, similar to the picture on the right, that's not a blueberry muffin. For it to be a proper blueberry muffin like the one on the left, then the
- 5:29
blueberries need to have been baked in from the start. It's the same thing with an accessible website. If you have a fully built website and then once it's done you start shoving in ARIA labels in different places, that is not an accessible website. For it to be an accessible website, you need to put accessibility at the forefront at every build process. And this does not just apply to developers. Accessibility is the responsibility of everyone. So we want to make sure that even from the business idea to design to QA, that we're ensuring that we're looking for accessibility and testing that can this product be used by everyone in the exact same way.
- 5:59
Another issue with waiting to the end to consider accessibility is that you waste a lot of time on regression testing. So if you've waited until your website is fully built and then you start testing and going back to fix issues, you end up refactoring and rewriting a lot more code than you'd have had to do if you just built it to be accessible from the start. And then of course, there are business consequences to building inaccessible products. The thing I hear sometimes is that a business might say, "Oh, but we don't have to consider accessibility because none of our users rely on assistive technologies." And I think that's very funny because it's sort of a self-fulfilling prophecy. It's not that your users don't rely
- 6:29
on assistive technologies, it's that people with assistive technologies cannot use your website in the first place, so they just never go to it. Imagine a business that didn't have a door. You would never get any customers. How would they get in the building? It's the same thing with building an inaccessible product. If you build a product that people cannot use, then people will not use it. And then finally, there are legal repercussions to not making your website accessible. In the United States, the Americans with Disabilities Act states that any public-facing product must be accessible and can be used by people with disabilities, or you could face fines and even lawsuits. But on the plus side, you
- 6:59
could get to use this really cute sticker on Microsoft Teams, so you know, weigh your options. Based on all this, we can see that it actually is a lot more expensive to be building products that aren't accessible. You're exposing yourself to losing money from customers, possible lawsuits where you have to pay fines. You're spending more time building code and refactoring things. So if you do build your product to be accessible from the start, it's going to be a lot faster and a lot cheaper. So now that we know all that, how can we actually ensure that our AI agents are building things to be accessible? Because everyone's code base is different
- 7:29
and we can be working with different technologies, I'm just going to give an overarching general view of how to get your AI agents to produce accessible code. So firstly, you need to define your accessibility requirements. Accessibility requirements differ based on what platform you're working on, so you do need to carry out research and ensure that you know what accessibility requirements you're supposed to be meeting for the platform you are building for. Once that's done, you need to audit your existing code base. So if you're going to introduce an AI agent into your code base, you need to ensure that you don't have any preexisting issues that the AI agent might copy
- 7:59
as what it thinks is best behavior. So you can use automated tools to carry out accessibility testing, or you can even tell your AI agent to do it, but you want to identify any existing issues and then fix them before you start writing new features. Then you want to implement some sort of reusable system. This is a very nice to have, but basically, if you're going to be working with accessibility, it's a lot easier to fix things in one component that is used in multiple places as opposed to making fixes to the same components across different files. So just having an implemented design system or any form of reusable
- 8:29
component library is going to save you a lot more time in the long run when making things accessible. And then finally, you want to enforce a mandatory accessibility skill. This is a skill that your AI agents will basically use anytime you're running anything related to maybe generating UI or writing code that requires accessibility. One skill that I really like to use is the Modern Web Guidance skill from Chrome. It's basically a skill that ensures that your agent is using the newest HTML and CSS features as opposed to custom JavaScript implementations. You can also have a lightweight version of an accessibility skill. I think this is very important, especially if you're
- 8:59
like vibe coding, where you're not working in a big code base. You just want something quick that your agent can refer to and not carry out a lot of in-depth research. This is what I would recommend for meeting like bare minimum accessibility requirements. So you want to make sure that you're using semantic HTML wherever possible, only reaching for ARIA when semantic HTML can't express the behavior. Every interactive element, if it can be operated by a mouse, it should also be operated by a keyboard. You want to make sure that elements are properly labeled and can be read by screen readers. And then finally, before running the code, your agent carries out an audit against all those steps. Of course, this is not enough to build a
- 9:28
fully accessible website. You still need to carry out a lot of manual testing yourself because it's not possible for one tool to make a website fully accessible. But just having these skills in place can help a lot more than not having them there at all. Regardless of why you use AI, most times the goal is to solve a particular problem. So just make sure that your solution is useful to as many people as possible. So build things to be accessible. And that is all. Thank you so much for listening to my talk. I hope you enjoyed it. If you do have any questions, feel free to reach out to me online @JemimaAbu. That's LinkedIn,
- 9:58
Twitter, or GitHub. I would love to hear from you. Okay, bye.