I ran axe DevTools on a client’s site last spring and it came back green. Zero critical violations. The owner forwarded me an email that same week: a screen reader user had filed a complaint because every form error on their checkout page was announced to assistive tech as nothing. Silence. The failure was real, WCAG 4.1.3, and completely invisible to the scanner. That moment is why I stopped trusting automation scores and started treating them as one input in a larger process. Here is the honest breakdown for small teams.
What Automated WCAG Testing Tools Actually Catch
Automated scanners evaluate code against WCAG success criteria that can be checked programmatically. Think missing alt attributes, insufficient color contrast ratios, empty form labels, missing page language declarations, and heading levels that skip from H1 to H4 without reason.
In practice, on the sites I audit, automated tools catch between 30 and 40 percent of total WCAG failures. That range matches the published research: WebAIM’s guidance and Karl Groves’ analysis of WCAG testability put reliably automatable success criteria at 25 to 33 percent, while Deque’s own study claims 57 percent on mature codebases. When I run a full manual pass after an automated sweep on a typical small business site, roughly two out of every five violations were flagged by the tool. The other three were not.
Here is what the good tools reliably catch:
- Contrast failures. Text under 4.5:1 against its background (3:1 for large text) per WCAG 1.4.3. This is the single most common automated finding I see on SMB sites, usually from gray-on-gray footer text.
- Missing or empty alt text. WCAG 1.1.1. Tools flag
imgtags without an alt attribute, though they cannot judge whether the alt text that does exist is any good. - Form labeling. Missing
label, missingforattributes, placeholder text used as the only label (WCAG 1.3.1 and 3.3.2). - Keyboard traps and focus issues. Partially. Tools flag elements with positive tabindex and missing focus indicators in code, but not whether focus order makes logical sense.
- Missing document landmarks. No
main,nav, orheaderregions that screen readers use for orientation. - ARIA misuse. Invalid roles, duplicate IDs, aria-labelledby pointing at elements that do not exist.
Tools like axe DevTools (free extension; Pro is published at $60 per user per month), WAVE by WebAIM (free), Lighthouse (built into Chrome DevTools, free), and Pa11y (open source, command line) all cover this territory well. Siteimprove and Tenon sit at the enterprise end, starting in the thousands per month: overkill for most small businesses.
What Automation Misses, and Why It Matters for ADA Risk
The failures that generate lawsuits and real user pain are disproportionately in the category scanners cannot judge. A tool can verify an alt attribute exists. It cannot tell you the attribute contains “image1.jpg,” which is technically compliant and functionally worthless.
The big misses:
- Screen reader usability. Does a modal trap focus correctly? Are dynamic updates announced? Is the reading order sensible? Only a human with a screen reader (NVDA is free, VoiceOver ships with macOS and iOS) can answer these.
- Meaningful alt text quality. WCAG 1.1.1 requires alt text to serve the purpose of the image. Automation checks presence, not quality.
- Context-dependent criteria. “Consistent navigation,” “consistent identification,” “labels or instructions” - these require judgment calls about the page as a whole.
- Reflow and zoom behavior. Content that breaks at 200% zoom or 320 CSS pixel width often passes automated checks.
- Keyboard operability in practice. A scanner sees focusable elements. It does not experience tabbing through a mega menu that closes the moment focus leaves its parent item.
This is the gap where most ADA demand letters live. The serial plaintiffs filing web accessibility suits in 2025 and 2026 are overwhelmingly targeting form failures, overlay popups that block screen readers, and checkout flows - all things that need human testing. If you want practical guidance on building error-free inputs, review my accessible forms WCAG guide. For background on the legal side, I covered the broader filing patterns in ADA website lawsuit trends.
One regulatory detail worth pinning down. The DOJ’s April 2024 Title II final rule adopts WCAG 2.1 Level AA as a binding standard, but only for state and local government sites, with compliance deadlines of April 2027 for entities of 50,000 people or more and April 2028 for smaller ones. Private businesses under Title III have no equivalent regulation yet; the DOJ holds that the ADA applies to websites generally and points to WCAG as the reference point. In practice, WCAG 2.1 AA is the benchmark in demand letters and settlements either way, as outlined in our complete web accessibility guide.
Where AI-Assisted Tools Change the Equation
The newer wave of tools, axe DevTools Pro with its intelligent guided tests, SortSite, and accessibility layers inside QA platforms like Applitools and BrowserStack, use machine learning to do things rule-based scanners could not.
Guided tests ask a human a few questions (“Does this element receive visible focus?”) and then automate the checking. In my experience this closes maybe half of the judgment gap: focus visibility, modal behavior, and form error announcements. It is still not a screen reader session.
AI-assisted alt text generation is the other big shift. Axe’s alt text feature and plugins for Figma and CMS platforms can draft alt text from image content. I tested these on e-commerce product pages: on clean, single-subject product shots, usable alt text about 70 percent of the time. On anything complex - charts, infographics, images with overlaid text - full rewrites in every case. Treat AI alt text as a first draft, never a final answer.
The caution: accessibility overlay widgets do not fix your underlying code, do not hold up in court, and several major disability rights organizations have formally opposed them. The National Federation of the Blind revoked accessiBe’s convention sponsorship in 2021 over its product practices, and the community-maintained Overlay Fact Sheet has been signed by more than 1,000 accessibility professionals. The DOJ’s guidance on web accessibility and the ADA warns that automated checkers “need to be used carefully” and that a clean report does not necessarily mean everything is accessible. Overlays do not get you there. Some plaintiffs’ firms now specifically name overlay users as targets.
Tool Comparison for Small Teams
| Tool | Price (approx.) | What it catches well | Weakness |
|---|---|---|---|
| axe DevTools | Free extension; Pro ~$40/user/mo | Contrast, ARIA, guided tests | No screen reader simulation |
| WAVE (WebAIM) | Free | Visual, in-page feedback, contrast | Manual page-by-page, no crawling |
| Lighthouse | Free (in Chrome) | Quick score, SEO tie-in | Shallow on WCAG, flags only obvious issues |
| Pa11y | Free (open source) | CI/CD integration, bulk crawling | No GUI, needs setup |
| NVDA + manual testing | Free | Screen reader reality | Time cost, learning curve |
| Siteimprove / enterprise suites | $2,000+/mo | Crawling at scale, reporting | Price point built for enterprises |
| Overlay widgets | $50-500/mo | Cosmetic widget only | Doesn’t fix code, legal risk |
For a small business with one developer, my honest recommendation is axe DevTools free plus NVDA, run quarterly. That combination costs nothing and covers more ground than a $500-a-month overlay.
What Most Guides Get Wrong
Three things I consistently see in competitor content on this topic:
A green scan score is treated as a finish line. It is not. The 2026 WebAIM Million analysis ran an automated scan of the top one million home pages and found detectable WCAG failures on 95.9 percent of them, averaging 56.1 errors per page. Low-contrast text alone appeared on 83.9 percent of them. Almost every one of those site owners could show you a passing Lighthouse score. Automated passes measure a subset of criteria; the subset is what fails in the real world.
More ARIA is sold as more accessibility. The opposite is often true. The same WebAIM data shows pages with ARIA present averaged 59.1 detected errors versus 42.0 on pages without it, and 22 percent of pages using ARIA menus introduced barriers because the required keyboard markup was missing. ARIA is a repair tool for cases where native HTML cannot do the job. A native button beats role="button" on a div every time: focus, keyboard activation, and state announcements come for free.
The regression problem is ignored. Accessibility is not a project you finish. WebAIM’s 2026 report attributes part of the rise in errors to AI-assisted coding: generated components ship unlabeled inputs and div-based buttons at scale. Whatever you fix this quarter will break the next time a form or modal gets regenerated. That is why the quarterly cadence below exists, and why the test log matters more than any single scan.
A Practical Workflow for Small Teams
You do not need an accessibility department. You need a repeatable process. Here is the quarterly cadence I set up for SMB clients:
- Week 1: Automated baseline. Run axe and Lighthouse on your top 10 pages by traffic (prioritizing high-intent URLs flagged in a technical SEO audit). Log every violation, grouped by WCAG level A, AA, AAA. Fix all Level A items first; those are what plaintiffs target.
- Week 2: Keyboard pass. Put the mouse away. Tab through every interactive element on those pages. Can you reach everything? Can you see focus? Can you operate menus, modals, and forms? This takes one focused hour per page and catches what most tools miss.
- Week 3: Screen reader pass. Install NVDA (Windows) or use VoiceOver (Mac). Complete your two most important user flows with your eyes closed: contact form submission and purchase or booking. If you get lost, your users get lost.
- Week 4: Remediate and document. Fix findings, re-run the automated sweep to confirm, and write down what you tested and when. Documentation of a good-faith process matters if a demand letter ever arrives.
Total cost: zero to $60 a month. Total time: roughly 12 to 16 hours a quarter. That is a realistic budget for a five-person company, and it puts you ahead of most of your competitors on both compliance and actual usability.
How This Fits Into a Broader Compliance Program
Accessibility testing is one layer. If you sell to enterprises or government-adjacent buyers, you will eventually face procurement questionnaires asking for a VPAT or ACR. The manual test results from the workflow above feed directly into that document, which is why I tell clients to keep their test logs even after fixes are deployed.
The same split shows up in security scanning and content QA: automation finds the known issues, humans find the unknown ones. Those test logs are also your evidence trail if a demand letter ever lands.
Common Failure Modes I See Repeatedly
After auditing a few dozen SMB sites, the same problems show up constantly:
- Focus indicators removed for aesthetics.
outline: nonewith no replacement. Keyboard users lose their place entirely. WCAG 2.4.7. - Placeholder text as labels. Placeholders disappear on focus and many screen readers skip them. A Level A failure and extremely common on modern form designs.
- Modal dialogs without focus management. Focus stays on the page behind the modal, so keyboard users tab into invisible content. Almost never caught by scanners.
- Infinite scroll without announcements. Screen reader users have no idea new content loaded. WCAG 4.1.3 status message criteria are among the most frequently failed in my manual passes.
- AI-generated alt text deployed unreviewed. I found a real estate site where the AI described every listing photo as “a picture of a room.” Technically present alt attributes, zero accessibility value.
The ROI Case in Plain Numbers
Small business owners ask me whether accessibility work pays. Three numbers I give them:
- A single ADA demand letter costs $5,000 to $25,000 to settle, before legal fees, per matter. The quarterly workflow above costs maybe $500 in labor.
- Roughly 1 in 4 U.S. adults lives with a disability, per the CDC. That is a quarter of your addressable market, and many of those users will leave a site they cannot operate rather than call you.
- The W3C WAI business case for accessibility documents the overlap with SEO, usability, and mobile performance. Alt text helps image search. Semantic HTML helps crawlers. Keyboard support helps every power user.
The overlay vendors sell fear at $500 a month. The scanner-plus-human process I described costs almost nothing and actually reduces legal exposure, because it produces the documented good-faith effort that courts and plaintiffs’ attorneys weigh.
Getting Started This Week
If you do nothing else after reading this, do these three things in the next seven days:
- Run Lighthouse on your homepage and top 5 landing pages. Fix every Level A violation it flags.
- Test your contact and checkout forms with only your keyboard. No mouse. Log what breaks.
- Install NVDA or open VoiceOver and complete one full purchase or booking flow. Note where you get lost.
That is more accessibility testing than most of your competitors have ever done. It is also the foundation for the documented process that protects you legally and the actual usability that keeps a quarter of the market on your site.
Conclusion
AI-assisted accessibility tools are worth using. They catch 30 to 40 percent of WCAG failures in minutes instead of days, and the newer guided tests stretch that further. But they do not replace a human with a keyboard and a screen reader, and nothing about an automated score changes what a court or a plaintiff’s attorney will look at. For a small team, the winning formula is cheap and boring: axe DevTools or WAVE for the automated baseline, a quarterly keyboard and screen reader pass on your highest-traffic flows, written records of what you tested, and no overlays. Run that loop for a year and you will be more accessible than most enterprise sites, at a cost most businesses spend on coffee.
