AI can fix some accessibility issues automatically, but only the narrow set a machine can both detect and decide. It can add a missing lang attribute, suggest a darker text colour that clears the 4.5:1 contrast ratio, or wire up an input to the visible label sitting next to it. It cannot decide what an image means to your reader, whether an error message makes sense, or whether a caption is accurate, and those judgement calls make up a large share of WCAG. AI accessibility remediation is therefore a drafting aid, not a conformance method. The W3C's guidance on evaluation tools says it plainly: tools "can not determine accessibility, they can only assist in doing so" (W3C WAI). The US Federal Trade Commission made the same point with money. In 2025 it finalised an order requiring accessiBe to pay $1 million over claims that its AI product could make any website WCAG-compliant, and barred the company from repeating those claims without evidence (FTC). The useful question is not whether AI can fix accessibility. It is which fixes you can hand to it, and who checks the rest.
What can AI accessibility remediation actually fix?
The mechanical failures. These are the ones where a rule can prove the problem and there is one obviously correct answer.
The WebAIM Million gives a good picture of what those look like. In its February 2026 run, six error types accounted for 96% of all errors detected on a million home pages: low contrast text (83.9% of pages), missing image alt text (53.1%), missing form labels (51%), empty links (46.3%), empty buttons (30.6%) and missing document language (13.5%) (WebAIM). Some of these are close to fully automatable:
- Missing document language.
<html>with nolangattribute fails WCAG 3.1.1. If the page text is German,lang="de"is the fix. A model gets this right almost every time. - Low contrast. Given
#8a8a8aon white, a tool can compute the ratio, see that it misses 4.5:1, and propose the nearest shade that passes. A designer still has to accept the new colour, but the arithmetic is solved. Our contrast checker does exactly this calculation. - Unlabelled inputs with a visible label. If
<input id="email">sits under a<span>Email address</span>, turning that span into<label for="email">is a safe, reviewable change.
Notice what these have in common. The correct answer is already on the page or follows from a formula. AI is good at that kind of edit, and it is genuinely useful to have a model draft forty of them in a pull request instead of a developer typing them by hand.
Where does AI get accessibility wrong?
Anywhere the fix depends on intent. The same WebAIM list contains items that look mechanical but aren't.
Take missing alt text. Detecting it is trivial. Fixing it is not, because WCAG 1.1.1 asks for a text alternative that "serves the equivalent purpose" of the image (W3C). Purpose depends on context. The same photo of a running shoe needs "Trail runner, grey with orange sole, side view" on a product page, and alt="" when it is a decorative banner next to a heading that already says the same thing. A vision model sees the pixels. It does not know why the image is there.
The W3C's working draft on machine learning and accessibility reaches the same conclusion. It notes that automated alt text has improved, "but criticism persists due to limitations in providing detail and recognising the importance of relevant data" (W3C APA, Editor's Draft, March 2026). That is a careful way of saying the model describes what is visible, not what matters.
Captions follow the same pattern. The W3C is direct about it: "Automatically-generated captions do not meet user needs or accessibility requirements, unless they are confirmed to be fully accurate" (W3C WAI). Auto-captions are a fine first draft. Someone still has to watch the video and fix the product names the speech model misheard.
Then there is the category AI rarely even sees:
| Issue | Can AI detect it? | Can AI decide the fix? |
|---|---|---|
Missing lang attribute | Yes | Yes, usually |
| Contrast below 4.5:1 | Yes | Proposes a value; a designer approves |
| Missing alt text | Yes | Drafts a description; a person checks purpose |
| Empty icon button | Yes | Guesses from the icon; often wrong for custom icons |
| Focus order that doesn't match the layout | Rarely | No |
| Error message that is unclear or not announced | Partly | No |
| Captions that are inaccurate | No | No |
The bottom half of that table is where people using screen readers and keyboards actually get stuck.
Is an AI fix at runtime the same as fixing your code?
No. This is where most of the marketing goes wrong.
Some products run AI inside the visitor's browser. A script loads with the page, inspects the DOM, and injects attributes or rewrites elements on the fly. The source code never changes. That approach has two problems. The first is that the fixes are only as good as the model's guesses, applied without anyone reviewing them. The second is that the result exists only while the script loads and runs correctly on that page, for that visitor.
The accessiBe case is the public record of where that model leads. The FTC alleged that accessiBe told customers its accessWidget could "make any website compliant with the Web Content Accessibility Guidelines (WCAG)", and that this was "false, misleading, or unsubstantiated" (FTC). According to the complaint, the pitch was that one line of code covered 30% of WCAG immediately and an AI process handled the other 70% within 48 hours (FTC case page). The final order bars the company from "representing that its automated products can make any website WCAG-compliant or can ensure continued compliance with WCAG over time" unless it can substantiate that (FTC). We covered the full case in the accessiBe FTC settlement, explained.
My view is simple. AI belongs in the pull request, not in the page at runtime. A fix in the source can be reviewed before it ships and shown to an auditor afterwards. A fix guessed in a visitor's browser has neither.
Why can't AI close the gap that automated testing leaves?
Because you can't fix what you can't detect, and detection has a ceiling.
Deque's 2021 study of more than 2,000 audits found that automated testing identified about 57% of issues by volume (Deque). Counted by success criteria rather than by issue volume, the share is lower, which is where the honest 30 to 57% range comes from. The W3C draft on machine learning says the same about tools in general: they have "restricted capacity of executing low-level coverage in checking and recommending remediations, with the remaining requiring some form of intervention" (W3C APA).
Adding a language model on top of a scanner does not raise that ceiling much. The model can only act on what the rule engine finds, plus whatever it can infer from markup. It cannot press Tab through your checkout, hear what NVDA announces when the card is declined, or notice that the "Continue" button is visually after the terms checkbox but comes before it in the focus order. Our own scanner doesn't catch those either. You need a person with a keyboard and a screen reader for that hour of testing, and there's no shortcut around it.
How should you use AI in accessibility work?
As a fast junior engineer whose work always gets reviewed. In practice that looks like this:
- Scan first. Get the list of failures with rule IDs and selectors, for example
color-contraston.price-badge. A free scan gives you that list. - Let AI draft the mechanical fixes in source: contrast values, missing
lang, label associations. Put them in a pull request, not a runtime script. - Anything about meaning stays a draft. Alt text, link text, error messages and captions get a human edit before merge.
- Re-scan to confirm. When you mark a fix in our product, we re-scan the affected pages and report whether the failing element is still present. A fix that didn't land shows up as still present rather than silently closing.
- Test the rest by hand. Tab through every flow, then do it again with a screen reader running. Our WCAG checklist lists the criteria a scanner leaves undecided.
This matters for legal frameworks too. The European Accessibility Act and the ADA care about whether people with disabilities can use your service, not about which tool you ran. In the EU, the harmonised standard EN 301 549 sets out how each requirement is checked, and many of those checks need a human verdict. AI-drafted fixes can speed up the work that feeds those verdicts. They don't replace them.
FAQ
Can AI make my website WCAG compliant automatically?
No. AI can fix a subset of mechanical failures, but a large share of WCAG criteria need human judgement, and in 2025 the FTC required accessiBe to pay $1 million over claims that its AI product could make any website compliant (FTC).
Is AI-generated alt text good enough?
It is a useful draft, not a finished answer. WCAG 1.1.1 asks for alt text that serves the image's purpose in context (W3C), and a model sees what is in the picture, not why it is on the page.
Are auto-generated captions acceptable?
Only once someone confirms they are accurate. The W3C states that automatically generated captions do not meet accessibility requirements unless they are confirmed to be fully accurate (W3C WAI).
What is the difference between AI remediation and an overlay?
Where the fix lives. AI-assisted remediation in the source produces code changes you can review and keep. An overlay changes the page in the visitor's browser at runtime, and the source stays broken underneath.
What share of accessibility issues can automation find?
Roughly 30 to 57%, depending on whether you count by issue volume or by success criteria. Deque's study of more than 2,000 audits put it at about 57% by volume (Deque).
See what a machine can find on your site
Run a free scan to get the automated findings with the rule, the mapped success criterion and the exact selector for each one. That is the part AI can help you fix. The rest still needs a person, and the report says so.
Pavel Charkasau, founder, wcagc.com Last updated: 26 September 2026
Sources
- W3C WAI, Selecting Web Accessibility Evaluation Tools — https://www.w3.org/WAI/test-evaluate/tools/selecting/ (accessed 26 September 2026)
- FTC, FTC Approves Final Order Requiring accessiBe to Pay $1 Million (22 April 2025) — https://www.ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million (accessed 26 September 2026)
- FTC, FTC Order Requires Online Marketer to Pay $1 Million for Deceptive Claims that its AI Product Could Make Websites Compliant with Accessibility Guidelines (3 January 2025) — https://www.ftc.gov/news-events/news/press-releases/2025/01/ftc-order-requires-online-marketer-pay-1-million-deceptive-claims-its-ai-product-could-make-websites (accessed 26 September 2026)
- FTC, accessiBe Inc. case page (File No. 2223156) — https://www.ftc.gov/legal-library/browse/cases-proceedings/2223156-accessibe-inc (accessed 26 September 2026)
- WebAIM, The WebAIM Million (February 2026) — https://webaim.org/projects/million/ (accessed 26 September 2026)
- W3C, Understanding Success Criterion 1.1.1: Non-text Content — https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html (accessed 26 September 2026)
- W3C Accessible Platform Architectures WG, Accessibility of machine learning and generative AI (Editor's Draft, 28 March 2026) — https://w3c.github.io/ai-accessibility/ (accessed 26 September 2026)
- W3C WAI, Captions/Subtitles — https://www.w3.org/WAI/media/av/captions/ (accessed 26 September 2026)
- Deque, Automated testing study identifies 57% of digital accessibility issues (10 March 2021) — https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/ (accessed 26 September 2026)