AI-generated code (code generated with Artificial Intelligence) often fails to meet WCAG (Web Content Accessibility Guidelines). That part is no surprise. Most websites do not meet WCAG either, so the training data is full of inaccessible code.
Something less expected happens during accessibility remediation: the work of fixing code that fails a WCAG Success Criterion. AI struggles with ARIA (Accessible Rich Internet Applications) patterns even when I give it specific instructions.
I find the problem in the existing code. I describe the exact fix. The AI still gets it wrong.
The problem
Here are 2 examples from recent work.
Example 1: vertical tabs
I asked an AI to apply the Tabs ARIA pattern to existing code. It produced the pattern for horizontal tabs instead of vertical ones.
This is not a subtle judgement call. You can see the orientation of the tabs by reading the code. I pointed out the error, and the AI rewrote the pattern for vertical tabs only. It did not write one implementation that handles both orientations.
Example 2: a complex table
I asked an AI to make a table accessible. The table had several column and row header cells, plus a final row of totals. I listed exactly what I wanted:
- a caption
- row groups: table header, body and footer
- a unique
idattribute on every header cell - a
headersattribute on every data cell, listing all of its header cells
The AI linked data cells to the wrong header cells and missed some of the right ones. The rule here is simple: a data cell belongs to the header cells in its own row and its own column. So why can’t AI apply it?
Looking for an answer
My first assumption was that training data is the main problem. Most websites implement WCAG badly, so the model sees few correct examples and many broken ones.
That assumption is too simple. Most people make grammar and typing mistakes when they write, and that does not stop AI from writing correctly.
So let’s look at the research.
Comparing AI code with human code
The paper “Human or LLM (Large Language Model)? A Comparative Study on Accessible Code Generation Capability” is the closest to my problem. It compares code written by AI with code written by people. It also compares naive code generation, where the prompt never mentions accessibility, with code improved through repeated prompting.
The first finding matches my experience:
“LLMs excel at addressing basic accessibility requirements but struggle with complex accessibility requirements, particularly ARIA-related attributes, performing worse than human developers.”
Human or LLM? A Comparative Study on Accessible Code Generation Capability, Hyunjae Suh, Mahan Tafreshipour, Sam Malek, and Iftekhar Ahmed, University of California, March 2025
In plain terms: AI handles the easy requirements and falls behind human developers on the hard ones. ARIA is the weakest area.
The second finding is more interesting:
“Advanced prompting techniques consistently generate code with lower accessibility issues than human-written code, yet they fail to consistently surpass Naive Code Generation, indicating inherent limitations in addressing accessibility through prompting alone.”
Human or LLM? A Comparative Study on Accessible Code Generation Capability, Hyunjae Suh, Mahan Tafreshipour, Sam Malek, and Iftekhar Ahmed, University of California, March 2025
In plain terms: better prompts beat human-written code, but they do not reliably beat AI’s own first attempt. Prompting alone has a ceiling. The authors tested Zero-Shot, Few-Shot and Self-Criticism prompting (3 standard ways of framing a request) and found no significant improvement.
They then proposed and tested a method called FeedA11y. It has 3 steps:
- Generate the code without any accessibility instructions.
- Produce a report of the accessibility issues, using the rules from existing evaluation tools.
- Fix only the issues in the report. Add nothing else.
The result:
“FeedA11y consistently outperforms human-written code and all prompting techniques in accessibility, especially when leveraging Qwen2.5-Coder.”
Human or LLM? A Comparative Study on Accessible Code Generation Capability, Hyunjae Suh, Mahan Tafreshipour, Sam Malek, and Iftekhar Ahmed, University of California, March 2025
This fits what we already know about working with AI:
- Asking for many things at once produces inconsistent results.
- Separating the context that writes the code from the context that checks it produces better results.
- Defining how success will be measured usually works better than listing the steps to get there. The exception is when the steps themselves matter.
What the wider literature says
“Large Language Models for Web Accessibility: A Systematic Literature Review” (Wajdi Aljedaan, Saudi Data & AI Authority, and Rubel Hassan Mollik, University of North Texas, May 2026) is a meta-analysis, a study that combines the results of other studies. It covers 38 papers on LLMs and accessibility, so it gives a broader view than any single experiment.
Three findings stand out:
- Every study uses WCAG as its reference. None of them uses supplementary material such as the COGA (Cognitive Accessibility) guidance.
- Most studies test common commercial LLMs and prompting techniques. Few explore other models or architectures.
- Research concentrates on semantics and perceivability. It rarely covers cognitive load, consistent navigation or task complexity.
The paper is direct about what this leaves out. People with disabilities are rarely involved in the studies, and when they are, the groups are small or mixed. So the evidence shows technical feasibility and comparative performance, not “real-world usability or lived experience”.
That leads to the most valuable conclusion in the review: accessibility depends on human behaviour, and technical improvements will not change that.
Conclusions
The situation splits in two.
- Anything a computer can detect and measure can be improved. Most of that improvement comes from how you design the pipeline, not from how you word the prompt.
- Everything else still needs people, including people with disabilities, testing real tasks.
You can act on the first part today. Treat WCAG conformance as a technical standard inside your review and test pipeline. AI can help you get there. It produces better output when the requirement is checkable, and it takes the guesswork out of rules that are easy to implement.
The second part is where the real gains are waiting. Cognitive accessibility is the direction WCAG is moving in, and it is the area AI research has barely touched.
We have work to do.