Quick answer: Automated accessibility scanners catch roughly 20-30% of WCAG success criteria, but closer to 57% of the actual errors they find. That gap matters more than it sounds: the errors AI tools miss by definition are the ones a real user hits — a keyboard trap, a form that doesn’t say which field is wrong, a link that says “click here.” In 2026, 3,117 website accessibility lawsuits were filed in U.S. federal courts, up 27% in a single year, and 95.9% of the top one million home pages still had detectable WCAG failures. The practical takeaway for a small business: run the automated scan first because it’s free and fast, but budget manual keyboard testing for the part that decides whether you actually pass.
Most small business owners I talk to have one of two reactions to the word “accessibility.” Either they assume it means a screen-reader user will somehow stumble onto their site and sue them, so they do nothing. Or a well-meaning agency quoted them a $15,000 audit and told them they were legally obligated to pass WCAG 2.2 AA today. Both reactions waste money in opposite directions.
Here’s the more useful framing. Automated and AI-powered scanning is genuinely good at what it does — it finds contrast problems and missing alt text at a scale no human review could reach, and it takes about four minutes. It is also structurally incapable of judging whether your navigation makes sense, whether your error messages help, or whether someone can actually complete your contact form with a keyboard. This article breaks down exactly what the scanners catch, what they miss, what the legal situation actually is in 2026, and the cheapest-first order to fix things in.
There are two numbers in circulation and they’re both true, which is why the topic confuses people.
The first counts success criteria — the individual rules WCAG is built from. By this measure, automated testing catches roughly 20-30% of them. The UK Government Digital Service and Karl Groves have both published on this, and it’s the figure the accessibility community quotes most often [1].
The second counts individual errors — each specific broken thing on each specific page. Deque ran this analysis across 13,000+ audited pages and found that 57.38% of total issues were identified by their automated axe-core testing [2]. The higher number is real, and it’s higher because contrast failures and missing alt text each generate dozens of instances per page while focus order generates one.
So which one matters? For triage, the 57% figure is the useful one — it tells you that running a scanner genuinely removes more than half the fixable work. For risk, the 20-30% figure is the honest one, because it tells you that a clean scan is not a clean site. Note also that Deque’s own report concedes the residue: their data shows Status Messages (4.1.3) with zero automated detections against 1,337 manually-found issues, and Consistent Navigation (3.2.3) the same way. Those criteria are simply not machine-testable.
WebAIM scanned the top one million home pages in February 2026 using the WAVE engine. The headline number: 95.9% of home pages had detected WCAG 2 failures, up from 94.8% the year before [3]. Across all one million pages, 56,114,377 distinct errors were found — an average of 56.1 errors per page, a 10.1% increase year over year.
Ninety-six percent of those errors fall into six categories that have topped the list seven years running. Two dominate:
The other four — unlabelled form inputs, empty links, missing document language, and empty buttons — together account for most of the remainder. Every one of these is cheap to fix. A scan catches all of them in minutes, which is precisely why the scan is worth running.
This is the part that decides whether a site actually passes, and it’s where the legal exposure lives. These require a human judging whether something makes sense.
Success Criterion 2.1.1 requires every function to work from a keyboard. A keyboard trap is when focus enters a component — a modal, a lightbox, an embedded map — and Tab can never leave it. A person navigating by keyboard is now stuck on your page with no way forward. Deque’s data puts keyboard at 2.49% automated detection, with the overwhelming majority found manually. It’s also invisible in a screenshot review and undetectable by a static scan, because you have to actually press Tab.
Criterion 3.3.1 Error Identification requires that errors be described in text. Criterion 3.3.3 Error Suggestion requires saying how to fix it. A form that turns a field red, posts back “Error,” and gives no indication of which of seven fields failed is a common failure mode in small business sites — and a scanner will pass it, because the input technically has a label. WCAG 2.2 added 3.3.7 Redundant Entry, which requires that information already entered earlier in a process be auto-populated or selectable rather than retyped. For anyone asking the same address on a quote form and a contact form in the same session, that’s a new obligation [5].
Criterion 1.4.1 Use of Color says color must not be the only visual means of conveying information. A red-bordered field with no icon, no text, and no asterisk fails even though it “looks obvious” to the sighted designer. Deque measured automated detection on this at 12%.
A site can have a focus indicator that technically exists and still be unusable, if the ring is a 1px pale-grey outline against white that disappears at the exact moment someone needs it. Criterion 2.4.7 Focus Visible and 2.4.3 Focus Order both require manual judgment. WCAG 2.2 added 2.4.11 Focus Not Obscured (AA), which addresses a specific and frustrating real-world pattern: a sticky header or cookie banner that covers whatever element currently has focus, so keyboard users tab through a page and never see where they’ve landed.
WCAG 2.2 became a W3C Recommendation on 5 October 2023, adding nine success criteria to WCAG 2.1 and removing one (4.1.1 Parsing is now obsolete). Six of the nine new criteria sit at Level A or AA [6]. For a small business the ones that generate real work:
One more worth naming because it’s a Level A obligation people miss: 4.1.1 Parsing is removed in 2.2, meaning duplicate IDs are no longer a 2.2 failure — but it was a 2.1 requirement, so if you’re claiming conformance to 2.1 you still owe it.
Short answer: for a private small business in Washington, no. And any agency telling you otherwise is either overselling or talking about a different jurisdiction.
What is settled:
What is contested, and what actually matters to a Moses Lake shop with one page and a contact form:
No federal regulation directly requires a private small business to meet WCAG 2.2 AA. But courts have used the ADA’s “effective communication” obligation to treat WCAG conformance as the practical yardstick for that obligation, and plaintiffs’ firms have noticed that the standard is concrete and the tooling is cheap. The numbers show the pressure is real rather than hypothetical: 3,117 website accessibility suits were filed in federal court in 2025, a 27% increase over 2024’s 2,452, and those website cases accounted for 36% of all ADA Title III filings that year [8].
Here’s the detail most small business owners have never been told, and it’s genuinely useful. In 2025, New York federal courts saw 1,021 website accessibility filings and Florida saw 961, while California’s federal courts saw just four. That isn’t because California businesses are more accessible. It’s jurisdictional: New York district judges have generally concluded that online-only businesses are covered by the ADA, while both the federal and state appeals courts in California have concluded they are not [8]. Your exposure depends substantially on which state your customers and your business are in — and increasingly on which state a plaintiff’s attorney decides to file in.
One specific criterion does apply to you regardless of venue: WCAG 2.2 AA is the conformance target WordPress core itself targets [9], and the WordPress theme review team maintains an “accessibility-ready” tag with 18 required criteria covering skip links, landmarks, keyboard support, labelled form fields, and contrast [10]. Choosing an accessibility-ready theme puts you materially ahead of the 95.9% without any additional work.
Based on what the scan data says, here’s the sequence I’d use on a small business site, in priority order:
Steps one through four are a couple of hours of work on a typical small business site and remove more than half of all detected errors. Step five is the one that tells you whether you’re actually fine, and it takes about the same time.
Automated scanning is worth running and worth running now — it’s free, it’s fast, and it finds more than half the mechanical problems. But it is not a certification, and it is not evidence that your site is usable by the people the standard exists for. The 20-30% criteria coverage figure is the one to remember, because it means every clean scan you’ve ever paid for was measuring the easy half.
For most small businesses, the sensible 2026 position is straightforward: meet the basics that affect everyone regardless of disability — real contrast, real labels, keyboard operability, visible focus — and you’ve covered the large majority of both the accessibility benefit and the legal risk. You don’t need to chase full WCAG 2.2 AA conformance to be safe. You do need to stop assuming that passing an automated scan means you’re done.
Written by Douglas Gorden Jr of Gorden Web Design, serving small businesses across Central Washington.
Gorden Web Design & Computer Repair ·
223 W 3rd Ave, Moses Lake, WA 98837 · (509) 230-4576 · Mon-Fri 9:00am-5:00pm