We took a real list of already-flagged WCAG issues, the kind a normal audit turns up, and handed the whole list to an AI assistant with one instruction: fix these. Not build something new, just fix what was already broken.
Some of the fixes were clean and correct. A few made the report worse in a way we did not expect. The pattern that emerged was not random. It was almost boringly predictable once you knew what to look for, and that predictability is the useful part of this story.
The Stat: A comparative study evaluating GPT-4o and Qwen2.5-Coder on accessible code generation found that AI-generated code handles basic features like color contrast and alternative text reasonably well, but struggles with complex issues such as ARIA attributes. (Source: arXiv 2503.15885, "Human or LLM? A Comparative Study on Accessible Code Generation Capability")
The setup: a repair job, not a build job
This is worth separating from the more common experiment of asking an AI to build a component from scratch. We have covered that version before, when we asked an AI assistant to build an accessible form from scratch and it got a lot of it wrong. That test measured whether AI could design for accessibility with no starting point and no constraints.
This test measured something narrower and, honestly, more relevant to how most teams will actually use AI in the short term. Nobody rebuilds their whole site because of an audit. They get a list of flagged issues and they patch them, one at a time, against code that already exists. So we gave an AI assistant that exact experience: a real, representative list of the kind of issues a normal WCAG audit turns up, in an existing codebase, with instructions to fix each one without breaking anything else.
Five categories from that list are representative of the pattern we saw across the full set:
- Missing alt text on informational images
- A low contrast button that failed the 4.5:1 text contrast threshold
- An unlabeled form field
- A custom dropdown menu missing its ARIA role
- A focus outline that had been stripped by a CSS reset
What the AI got right
The AI assistant handled the first two issues cleanly. For the missing alt text, it wrote reasonable, contextual descriptions based on surrounding page content and image file names, rather than generic placeholder text. For the low contrast button, it correctly identified the failing color pair and adjusted it to meet the contrast ratio, without needing to be told the exact target.
It also caught the stripped focus outline immediately, restoring a visible focus indicator instead of just deleting the offending outline: none rule and calling it done. That is a meaningfully good fix, because a lazier fix (simply removing the override) can leave a browser default that is inconsistent across components. The assistant instead standardized a visible focus style across the affected elements, which is the more durable version of the fix.
This lines up exactly with what the underlying research would predict. The arXiv study comparing human and LLM-generated code on accessibility specifically found that models handle color contrast and alternative text reasonably well. Those are the kinds of issues with a clear, testable, largely mechanical answer: measure a ratio, describe an image. The model has plenty of training signal for both.
Where it quietly failed
The unlabeled form field and the custom dropdown were a different story, and this is also exactly what the research predicts: AI-generated code "struggles with complex issues such as ARIA attributes."
For the unlabeled form field, the assistant added a placeholder attribute with descriptive text and called the issue resolved. It was not resolved. A placeholder is not a label. It disappears the moment a user starts typing, it is not reliably announced by every screen reader in every state, and it fails WCAG 3.3.2 Labels or Instructions, which requires that a label be programmatically associated with its input, not just visually implied near it. The correct fix needed a proper <label for> association or an aria-labelledby reference, and the model did not reach for either.
The custom dropdown was worse, because the fix looked more convincing on the surface. The assistant added some aria-* attributes to the component, which made the diff look like real remediation work. But it did not correctly expose the component's role, name, and state the way a native or fully-scripted widget needs to under WCAG 4.1.2 Name, Role, Value. A screen reader user landing on the control still could not reliably tell it was a dropdown, what it currently held, or how to operate it. The markup had gained ARIA attributes without gaining actual accessibility, which is arguably a worse outcome than doing nothing, because it now reads as "fixed" in a quick visual code review.
That is the trap. A missing label is obviously missing. A wrong aria-* attribute looks like diligence.
The pattern, summarized
| Issue category | AI fix quality | Why |
|---|---|---|
| Missing alt text | Fixed correctly | Clear, testable, mechanical rule |
| Low contrast button | Fixed correctly | Measurable ratio, single correct answer |
| Removed focus outline | Fixed correctly | Restoring a visible style is straightforward |
| Unlabeled form field | Not actually fixed | Needed structural association, not just visible text |
| Custom dropdown missing ARIA role | Not actually fixed | Needed correct name, role, and state, not just any aria-* attribute |
A checklist for anyone doing this in practice
If your team is going to use an AI assistant to work through a flagged accessibility list, here is what we would recommend checking before you consider anything closed:
- Contrast and alt text fixes: spot-check a sample, but treat these as generally reliable
- Every form field fix: confirm a real
<label for>oraria-labelledbyexists, not a placeholder - Every custom widget (dropdowns, tabs, modals, accordions): test with an actual screen reader, not just a visual diff
- Any new
aria-*attribute: verify it is the correct role and state for that component, not just present - Focus styles: confirm the restored indicator is visible against its background, not just technically non-zero
- Re-run the original audit tool after the fixes, do not assume "closed" from the AI's own summary
The takeaway
AI can genuinely speed up the mechanical half of a remediation list. It is not faking the contrast fixes or the alt text, those were correctly reasoned. But the moment the issue involves a custom interactive component and its programmatic name, role, and value, the fix needs a second set of eyes, ideally a human who can actually test with assistive technology rather than just read the diff.
That is not a knock on the tool. It is a scope boundary, and knowing where it sits is what makes AI-assisted remediation safe to use instead of risky to use.
If you want a second opinion on a fix list before you ship it, whether it came from an AI assistant, a developer working fast, or both, get a human-reviewed audit before shipping any AI-generated fix. You can also reach our team directly at experts@wcag.world if you would rather talk through a specific flagged list before you commit to any fix.