The state of web accessibility tooling in 2026

A team lead emailed me last week with a screenshot of her tooling budget. Five line items, all accessibility-related: a linter in CI, a paid scanner that emails a weekly PDF, a browser extension her designers use, an overlay widget the marketing team installed without telling anyone, and a quarterly manual audit from a consultancy. Her question was simple. "Why do we have five of these and still fail our customer's WCAG audit?"

The answer is that those five tools do five different jobs, most of her team did not know which job each one was doing, and the expensive one at the bottom — the manual audit — was the only one finding the issues that were actually getting her flagged. That is the state of accessibility tooling in 2026: lots of tools, a lot of overlap, and a persistent gap between "we run a11y tools" and "our product is accessible." This post is a map of the landscape so you can tell which box each tool fits in and where the gaps are.

The honest ceiling on automated detection

Start with the number that frames everything else. Automated tools cannot find every WCAG issue. They cannot even find most of them. Deque, the company behind axe-core, has published guidance stating that automated testing with axe surfaces around 57% of common WCAG issues. That is the high end for a mature engine, and it is a number worth internalizing: even the best automated scanner leaves a large share of conformance requirements for a human to check.

This is not a knock on automation. It is a description of the problem space. A machine can reliably tell you an image has no alt attribute. It cannot tell you whether the alt text you wrote is meaningful, whether your tab order makes sense to someone using a screen reader, or whether your custom dropdown actually announces its state. Those require judgment. So every tooling stack worth building has two halves: automation that catches the deterministic failures fast and cheap, and human review for everything that needs a person. The mistake the team lead made was buying four automated tools and treating them as if they added up to full coverage. They do not. Four tools that each find the same 57% still find 57%.

Linters: the cheapest, earliest catch

The earliest place to catch an accessibility bug is in the editor, before it is ever committed. For React and JSX teams that means eslint-plugin-jsx-a11y, which flags a meaningful set of static issues — missing alt text, an onClick on a div with no keyboard handler, a form input with no associated label — as you type.

Linters are fast, free, and run on every save. Their limit is that they only see static markup. They cannot evaluate anything that depends on runtime state, computed color, or the assembled DOM. A linter will never catch a contrast failure that only appears after a theme switch, or a focus trap in a modal that only exists once the modal opens. Treat the linter as the first net, not the last one. It catches the cheap mistakes early so your more expensive tools are not wasting their budget on them.

Scanners: axe-core and the engines built on it

The next layer is the automated scanner — a tool that renders a page (or a component) and runs a rule engine against the live DOM. The dominant open-source engine here is axe-core, and a large share of commercial accessibility products are built on top of it, including ours. We run axe-core v4.11 plus more than 50 proprietary rules layered on top to catch patterns the base engine misses.

Scanners come in two flavors, and the difference matters more than the marketing suggests. Some scan the rendered page in a browser; some scan the source. A page scanner tells you that a button on /checkout has insufficient contrast. A source scanner can tell you which component and which line produced it. Both are useful, and the better products do both — inklu runs web scans (2 tokens) against deployed pages and repository scans (8 tokens) against the codebase itself, because the rendered page tells you what is broken and the source tells you where to fix it.

What scanners share with linters is the same hard ceiling. They are still automated, so they still cap out around that 57% figure. A scanner that promises "100% WCAG coverage" is either redefining what coverage means or counting on you not to read the success criteria. Be skeptical of that claim wherever you see it. If you are comparing scanner vendors, our comparison pages lay out where the differences actually are — check each vendor's own site for current details, since feature sets move quickly.

Browser devtools and extensions: the designer's microscope

axe DevTools, Lighthouse's accessibility audit, and similar browser extensions occupy a specific niche: a human, looking at one page, wanting a fast read on that page right now. They are excellent for spot checks and for designers who want to inspect contrast or heading structure without leaving the browser.

Their limit is that they are manual and per-page. Nobody runs a browser extension across 400 routes on every deploy. So extensions are a debugging and exploration tool, not a coverage tool. They belong in the hands of the person fixing a specific issue, not in the part of your process that is supposed to guarantee nothing regressed. For that, you need automation in CI — which is a different tool doing a different job. We wrote about wiring accessibility checks into GitHub Actions if that is the gap in your stack.

Overlay widgets: the one to understand before you install

Overlay widgets — the JavaScript snippets that inject an accessibility toolbar and attempt runtime DOM fixes — are the most contested category in this market, so let me be measured about it. The appeal is real: one line of script, no engineering work, an instant-looking solution. For some narrow uses, like offering users a font-size or contrast toggle, a widget can add genuine value.

The thing to understand is what an overlay does not do. It does not change your source code. It patches the rendered DOM at runtime, which means the underlying markup a screen reader or a court-appointed auditor examines is unchanged, and the patch has to re-run and re-guess on every page load. When the overlay guesses wrong, you have a new bug that exists only in production and only for assistive-technology users — the hardest kind to reproduce. I have written a longer, evenhanded breakdown of overlays versus source-code fixes if you want the full argument; the short version is that an overlay is a layer on top of the problem, and the problem is still in your code. Decide with that clearly in mind.

Manual audits: still the only thing that finds the other 43%

The team lead's most expensive line item was the consultancy doing quarterly manual audits, and it was the one earning its keep. A skilled auditor using a screen reader is still the only way to catch the issues automation structurally cannot: ambiguous link text, illogical reading order, a custom component that is technically labeled but practically incomprehensible, a flow that works with a mouse and collapses with a keyboard.

The downside is obvious — manual audits are slow, expensive, and a snapshot in time. The page that passed in March regresses in April and nobody knows until July. The right model is not "automation or audits." It is automation running continuously to hold the line on the deterministic 57%, and periodic human audits for the judgment-dependent remainder, scheduled around your release cadence rather than the calendar.

Where the gap actually is: detection versus remediation

Here is the pattern under all five categories. Almost every tool in this market is a detection tool. Linters detect. Scanners detect. Extensions detect. Audits detect. They hand you a list and the fixing is your engineering team's problem, which is where accessibility work actually dies — not in the finding, but in the backlog where the findings sit for two quarters because nobody has time.

That gap between detection and remediation is the part of the landscape that has changed most recently, and it is the part we built inklu to close. Instead of emailing you a PDF of violations, inklu opens a GitHub pull request with an AI-generated fix for each issue — generated by GPT-4o, scoped to the relevant files, and never committed to your default branch without your review. You still get the detection that every other scanner gives you. You also get the diff. A web scan costs 2 tokens, a repository scan 8, and each auto-fix PR 1 token, on plans that start at $29/month — the pricing page has the full breakdown.

That does not eliminate the manual audit. Nothing on this list does; the 57% ceiling is real and we are honest about it. But it does mean the deterministic majority of your issues can be detected and remediated in the same motion, in the tool your engineers already live in, instead of piling up as tickets.

How to read your own stack

Lay your tools out the way the team lead finally did. For each one, write down two things: what it detects, and whether it fixes anything. Most teams discover they own three or four detection tools that overlap heavily and zero tools that close the loop to a merged fix — plus, often, an overlay nobody can quite account for. The fix is rarely "buy more scanners." It is closing the remediation gap and keeping one good manual audit in the rotation for the part machines cannot judge.

If you want to see what detection-plus-remediation looks like on your own codebase, book a demo at inklu.io and we will run a scan against a repo you choose and show you the pull requests it opens. Questions about where inklu fits next to a tool you already run? Email hello@inklu.io — we will give you the straight version, including what we do not do yet.