An AI coding assistant can generate an interface in seconds. It can also confidently tell you that it checked the interface for accessibility. That does not mean the interface is accessible. I have watched an AI tool report that it had completed its checks, only for the code to fail once it reached the team’s normal review process. The tool sounded certain, but the output did not hold up.
That gap matters because AI-assisted development is getting faster, more common, and more deeply embedded in how teams build products. When the tool produces a bad pattern, it does not stop to question it. It simply helps the team ship the pattern faster.
Recently, TXI invited Taylor Arndt and Jeff Bishop to speak with our team about accessibility, disability justice, and AI. Taylor, a blind software engineer, shared what happened when she asked Claude Code to build an interface for her. The result was filled with inaccessible buttons, cluttered regions, and structural problems that made the experience difficult to navigate with a screen reader. Her explanation was simple: AI learned from the internet, and most of the internet is not accessible. That means inaccessible output is not an unusual malfunction. It is a predictable result of the material these tools learned from.
AI defaults to what is common, not what is inclusive
Coding assistants are very good at finding a plausible way to complete a task. They are not automatically good at understanding whether that solution works for the people who will use it. Often, they reach for the fastest or most common implementation. Accessibility may be left out because it was missing from the examples the model learned from, the prompt it received, or the requirements the team provided. That can show up as obvious errors, such as a missing label or a heading used out of order. But the harder problems are rarely that simple.
A tool might be able to check whether an image has alternative text. It cannot determine whether that description gives a user the information they need. It might measure color contrast, but it cannot decide whether a complex workflow is understandable for someone with a cognitive disability. It might produce technically valid markup but It cannot know whether the experience works for a person navigating without a mouse, using a screen reader, relying on voice control, or processing information differently. That leads to the most important accessibility question a team can ask:
Accessible to whom? AI cannot answer that question without context. Even then, it should not answer it alone.
The missing input is not another prompt
Teams sometimes respond to these problems by adding more instructions.
They tell the tool to follow accessibility standards.
They create an accessibility prompt.
They ask it to verify its work before returning the code.
Those practices can help. We use versions of them ourselves. But a stronger prompt is not a substitute for understanding your users. Before a team can tell an AI tool what good looks like, the team has to know who the product is for, which needs matter most, and how those needs affect the experience being built.
That knowledge comes from research, conversation, testing, and repeated contact with the people using the product. It grows as the team learns what works, what fails, and what they overlooked the first time.
An AI coding assistant does not maintain that relationship. It does not talk with a user at the beginning of a project and return later to see whether the product works for them. It only works with the context the team has captured and chosen to provide. That is why human involvement cannot be reduced to approving the final code. The human role begins much earlier.
When the tool needs to be challenged
One of my TXI colleagues, Gilad Shanan, recently noticed a problem while testing a form with keyboard navigation.
He asked an AI coding assistant for help. The tool offered a solution that seemed reasonable at first, but it did not account for how the change could affect screen reader users. Gilad had to challenge the response, explain the experience he was trying to preserve, and continue working through the tradeoff before the tool produced a useful direction.
The important part of that story is not the specific code change. It is that the AI needed someone to notice what it had missed. The tool could generate options. Gilad had to understand the people affected by those options.
This is where AI’s confidence becomes dangerous. The response often arrives without visible uncertainty. A developer may receive an answer that reads like a settled best practice even when it is missing user context, applying a rule too broadly, or solving for one disability while creating a barrier for another.
The human in the loop cannot be a ceremonial reviewer. Someone has to know when to push back.
Accessibility has to live in the workflow
On one of our projects, we have started building accessibility guidance into the same workflows our AI tools use to generate and review code. Accessibility expectations appear during implementation, in acceptance criteria, and during pull request reviews. The goal is to make them part of the work instead of something the team remembers to check at the end. That reduces the need to repeatedly tell the tool the same thing. It also creates checkpoints where humans can verify what the tool produced.
We still test in the browser. We still use scanning tools. We still review the code. We still ask whether the experience makes sense for the users it is meant to serve.The AI-generated answer is an input, not proof. This matters for learning, too. When developers write a pattern themselves, they build habits through repetition. They remember that a field needs a meaningful label because they have implemented and tested that pattern many times.
When AI writes the first draft of the code, the developer moves into more of a review role. That can make work faster, but it can also weaken the muscle-memory that builds accessibility instincts. Teams adopting AI should be deliberate about maintaining those instincts. Speed is useful only when the team can still recognize what the tool got wrong.
By the time the code is written, many decisions are already made
There is one more reason accessibility cannot live only in code review. By the time an engineer opens a coding assistant, the team may have already made decisions about the users, requirements, workflow, content, design, and scope. If accessibility was absent from those conversations, the engineer is being asked to retrofit it into choices that are already set.
AI makes that risk more urgent because it can move quickly from requirement to implementation. When the requirements leave people out, the tool can turn that omission into working software before anyone stops to question it.
Accessibility needs to be discussed during discovery. It needs to influence design. It needs to appear in acceptance criteria. It needs to be tested with people whose experiences are different from those of the team building the product. Then AI can help the team work faster within a thoughtful system. Without that system, we’re gonna be in for even more bad internet.
AI can write the code, but it cannot know your users, earn their trust, or decide which tradeoffs are acceptable on their behalf. That judgment still belongs to us, and it’s up to us to keep using that judgement for the benefit of our users, and to keep our new code-copilots in check!
