Around 16% of the world's population lives with a significant disability. Meanwhile WebAIM's annual survey of the top million homepages keeps finding the same thing: over 94% have detectable WCAG failures, and the average homepage has dozens. The gap between "we care about accessibility" and "our signup form has labels" has never been wider — or more expensive.
Expensive, because the legal landscape moved. The European Accessibility Act (EAA) has applied since June 28, 2025: e-commerce and many digital services sold into the EU must be accessible, with member states attaching real fines. In the US, ADA lawsuits over inaccessible websites continue at thousands per year, and they disproportionately target small and mid-size businesses — the ones without an accessibility team.
This post is about the automation layer: what a scanner can genuinely catch, what it can't, and why "it's automated, so it's partial" is an argument for running it on every deploy rather than skipping it.
The Web Content Accessibility Guidelines (WCAG) 2.x organize requirements under four principles — content must be perceivable, operable, understandable, and robust. Conformance comes in levels; Level AA is the standard contracts, laws (including the EAA's underlying EN 301 549), and procurement checklists mean when they say "accessible."
In practice, AA translates into things like: every image conveys its information in text, every form field has a name, the page has a sane heading structure, keyboard users can reach and operate everything, nothing relies on color alone, and assistive technologies can parse the markup. None of this is exotic — most of it is HTML used the way HTML was designed.
Roughly a third to a half of WCAG failures have an objective, machine-checkable signature in the served HTML. That's the automation surface, and it covers the failures that are both most common and most embarrassing:
lang attribute — screen readers guess the pronunciation language without it<h1>s, skipped heading levels (h2 → h4) — headings are how screen reader users navigate; a third of WebAIM survey respondents navigate by headings first<main> landmark, duplicate ids, invalid ARIA rolesaria-hidden on focusable elements — keyboard focus lands on something screen readers are told doesn't exist<th>/scope)autocomplete on identity fields — WCAG 1.3.5; also what lets password managers and users with motor or cognitive disabilities fill forms reliably<fieldset>/<legend> — options with no audible question<label for> pointing at nothing, image buttons without alt texttabindex — hijacks focus order in ways that are nearly impossible to maintainuser-scalable=no) — overrides low-vision users' primary coping tool<marquee>/<blink>Every one of these is detectable in raw HTML, deterministic, and fixable in minutes once named. That's the profile of a perfect CI/scanner check.
No scanner can tell you whether your alt text is accurate, whether the heading order makes sense, whether keyboard focus is visible against your background, whether your custom dropdown is actually operable with arrow keys, or whether the checkout flow is comprehensible under a screen reader. Color contrast is only partially automatable from markup — most color lives in CSS and computed styles, so static HTML analysis catches just the inline-style subset.
Anyone selling "fully automated WCAG compliance" — particularly one-line JavaScript "overlay" widgets — is selling the impossible; overlay vendors' customers keep getting sued, and disability advocates have documented overlays making sites less usable. Treat scans as the floor: they catch the objective majority-by-volume failures on every deploy, and they free human review (one afternoon with a keyboard and a screen reader: tab through signup, checkout, and your core flow) to focus on the judgment calls automation can't make.
The right mental model: automated checks are accessibility signals, not certification. That's also why scanning beats auditing-once: an audit is a snapshot, while your templates change weekly. The unlabeled input ships back in with the next form refactor; the scanner catches it the same day.
Accessibility failures live in templates, but not only in the homepage template. Forms hide on contact and signup pages, tables on pricing pages, iframes on docs pages. A scan that samples interior pages — not just / — catches the template classes a homepage-only check structurally can't see.
The accessibility check is the eighth pillar in a CheckVibe scan, alongside security, SEO, and performance:
Accessibility issues also feed the compliance check's EAA-relevant signals, since "is the site accessible" is now a legal-exposure question, not just a quality one.
Run a free scan — if your forms are labeled and your headings are sane, you'll know in a minute. If they aren't, you'll know exactly where.
No. Automated checks reliably catch the objective failures — missing labels, alt text, language attributes, broken heading structure, focus traps in markup — which are the bulk of failures by volume. Judgment calls (alt-text quality, focus visibility, flow comprehensibility, full contrast analysis) need a human with a keyboard and a screen reader. Automation's job is catching the objective majority continuously so human review can be rare and focused.
WCAG is the W3C's accessibility standard; 2.1/2.2 are versions and A/AA/AAA are conformance levels. Level AA is the benchmark referenced by most laws and contracts — including the EU's EN 301 549 standard underlying the European Accessibility Act — covering things like text alternatives, labels, keyboard operability, contrast, and consistent navigation.
If you sell e-commerce or covered digital services to consumers in the EU, very likely yes — it has applied since June 28, 2025, regardless of where your company is based. Microenterprises (under 10 staff and under €2M turnover) have a service exemption, but their B2B customers increasingly demand conformance anyway. Member states enforce with fines; the practical baseline is WCAG 2.1 AA.
Year after year, WebAIM's million-site survey finds the same five: low-contrast text, images without alt text, form inputs without labels, empty links, and missing document language. Four of the five are trivially machine-detectable and typically one-line fixes — which is what makes shipping them in 2026 so unnecessary.
No. One-line overlay widgets cannot fix markup-level failures (they read the same broken DOM), they frequently interfere with users' own assistive technology, and companies using them continue to receive ADA demand letters — some lawsuits now cite the overlay itself. Fix the markup; it's less work than it sounds.
Paste your URL and get a security report in 30 seconds. 100+ automated checks with AI-powered fix prompts.
Scan your site free