Image: WCAG Pros (wcagpros.com)
WCAG 2.2 accessibility has become the clearest flashpoint in web development this year, and not because of a new success criterion. It’s because of what organisations are quietly installing to sidestep the real work.
Picture a mid-sized retailer bolting an accessibility widget onto their site after a legal demand letter arrives. Within a week, a screen reader user files another complaint – the checkout form still has no labels, the modal still traps keyboard focus, nothing has actually changed. The widget sits on top like a sticking plaster over a structural crack. So what’s actually broken underneath, and what fixes it?
What is WCAG 2.2 accessibility and why does it matter now
Image: WCAG Pros (wcagpros.com)
WCAG 2.2 accessibility means a site meets the W3C’s current success criteria across four principles – perceivable, operable, understandable, robust – verified by real testing, not just a scan. It’s worth being precise about what “meets” means here: WCAG defines three conformance levels, A, AA, and AAA, and almost every legal standard (the US ADA via case law, the EU’s European Accessibility Act, the UK’s PSBAU regulations) references AA as the practical bar. Claiming “full WCAG compliance” is a red flag in itself – AAA includes criteria, like sign language interpretation for all video, that most commercial sites never attempt. The honest claim is “AA conformance across applicable criteria,” not blanket compliance.
It matters now because enforcement has caught up with the standard: lawsuits, regulatory pressure, and user expectations all assume conformance is genuine, not cosmetic.
The scale of the gap is the problem. WebAIM’s annual Million report, which scans the homepages of the top one million sites, has found detectable WCAG failures on over 95% of them for several years running – automated detection, not full manual audit, so treat it as a floor on the real failure rate rather than a precise figure. That’s not a handful of edge cases – that’s most of the web shipping broken experiences to a meaningful share of its potential users; the CDC estimates roughly 1 in 4 US adults lives with a disability. The commercial cost compounds the legal one: usability research from groups like Click-Away Pound has repeatedly found that most disabled users abandon sites they struggle to use, which turns every inaccessible checkout flow into lost revenue, not just legal exposure.
Three things are true simultaneously here: accessibility is a legal risk, a UX problem, and a revenue leak. Treat it as only one of those and you’ll underinvest in the fix.
Do accessibility overlay widgets actually fix WCAG 2.2 compliance
No – overlay widgets adjust how a page displays on the visitor’s device, but they don’t touch the underlying code that causes most failures. Tools like accessWidget, UserWay, and EnableAll Assist-Bar work by injecting JavaScript at load time to manipulate the page’s DOM – the browser’s in-memory model of the page structure – purely at the client-side presentation layer.
That’s a meaningful distinction, not pedantry. A widget can bump contrast or resize text, which genuinely helps some visitors. What it can’t do is add a missing alt attribute to a product image, fix a form input with no associated label, or repair a heading hierarchy that jumps from H1 straight to H4. Those are source-code defects, sitting in the HTML and components your CMS renders, not in anything a browser extension can rewrite. No amount of client-side JavaScript adds semantic meaning that was never there – it can only paint over what’s already broken.
This is where automated scanning compounds the illusion. Industry analysis of tools like axe and WAVE generally puts automated coverage at somewhere between a quarter and a half of WCAG 2.2 success criteria, because algorithms can only test rules that are deterministic – does this image have alt text, does this button have an accessible name. They can’t judge whether that alt text is meaningful, or whether a keyboard user can actually complete checkout without getting stuck. A clean scanner report and a genuinely accessible site are two different claims, and conflating them is how overlay vendors sell false confidence.
Before and after: what source-code remediation actually looks like
Here’s a checkout form before and after remediation, since the abstract version of this argument is easy to nod along to and easy to ignore:
Before (fails multiple WCAG 2.2 criteria):
<input type="text" placeholder="Card number">
<div class="modal" onclick="closeModal()">...</div>
<img src="product-247.jpg">
No programmatic label on the input – a screen reader announces “edit text, blank.” Placeholder text disappears the moment someone starts typing, which is a problem for anyone with short-term memory or attention difficulties, not just screen reader users. The modal closes on click but has no keyboard handler and no focus trap, so a keyboard user can tab straight through to content behind it. The image has no alternative text at all.
After:
<label for="card-number">Card number</label>
<input type="text" id="card-number" autocomplete="cc-number">
<div class="modal" role="dialogue" aria-modal="true" aria-labelledby="modal-title" tabindex="-1">...</div>
<img src="product-247.jpg" alt="Navy wool overcoat, front view, with horn buttons">
The label is explicit and persistent. The modal announces itself as a dialogue, traps focus inside until dismissed, and returns focus to the triggering element on close – three separate behaviours, all requiring a few lines of JavaScript plus the right ARIA (Accessible Rich Internet Applications, the attribute set that describes custom widgets to assistive technology) attributes. The alt text describes what matters for a purchase decision, not “image247.jpg” or, just as uselessly, “image of a coat.” None of this is exotic engineering. It’s the difference between a form that works and one that doesn’t, and it lives entirely in markup a widget never touches.
What actually remediates WCAG 2.2 failures
Fixing WCAG 2.2 failures requires source-code and component-level engineering – native HTML, CSS, and ARIA work inside the core codebase, design system components, and CMS templates, applied consistently so the fix doesn’t regress the next time a template gets reused. Done properly, guided by audit findings, this can address the full set of applicable criteria for a given conformance target, because you’re fixing the actual defect rather than masking its symptom.
Expert-led manual testing with real assistive technologies – screen readers, switch devices, voice control – covers categories automated tools structurally can’t reach, including whether interactions actually make sense to someone using them. It’s the strongest evidence you can gather that a site works, but it isn’t a legal guarantee on its own: conformance is judged criterion by criterion, standards get updated, and a court or regulator looks at documented process and good-faith remediation as much as a single audit report. The practical model for commercial sites combines three layers: automated tools for continuous regression detection (including CI/CD pipeline integration), expert manual testing of key user journeys, and verified fixes committed to source, with the audit trail kept as evidence of ongoing effort. Each layer catches what the others miss, and the combination is what you’d actually want to show if challenged.
The nuance most teams miss
The real unlock is shifting left – building accessibility checks into your design system and editor tooling so violations surface before code ships, not after an auditor finds them. Real-time feedback catches focus traps, missing form labels, and broken heading hierarchies at the point of creation, when fixing them costs minutes instead of a remediation sprint.
Widgets aren’t worthless – they genuinely improve display controls for some users. They’re just not a substitute for accessible markup, and treating them as one is the myth that keeps getting companies sued.
So, back to that retailer: patching symptoms at the browser layer while the codebase stays broken was never going to hold up – not legally, not for users, not for the bottom line. WCAG 2.2 accessibility is won in the source code, verified against AA criteria by people who actually use assistive technology, with automation watching for regressions in between.
If your site needs that kind of code-level remediation rather than another overlay, DRS Web Development builds custom websites and web applications for businesses of all sizes – get in touch for a free consultation.
Frequently Asked Questions
Q: Do accessibility overlay widgets make a website WCAG 2.2 compliant?
A: No. Overlays adjust page display via client-side JavaScript but can’t fix underlying code defects like missing alt text, unlabelled form fields, or broken heading structures – the actual causes of most WCAG 2.2 failures.
Q: How much of WCAG 2.2 can automated scanners actually detect?
A: Estimates vary, but automated scanners generally cover somewhere between a quarter and a half of WCAG 2.2 success criteria, since algorithms can only check rules that are deterministic, not subjective qualities like whether alt text is meaningful.
Q: What’s the most reliable way to check WCAG 2.2 compliance?
A: Expert-led manual audits using real assistive technologies give the clearest picture of genuine usability and the strongest basis for a defensible remediation process, though no single audit guarantees legal outcomes on its own.
Q: Is “full WCAG compliance” a meaningful claim?
A: Not really. WCAG has three conformance levels (A, AA, AAA), and most legal standards reference AA across applicable criteria – a site should describe its conformance target precisely rather than claiming blanket compliance.
Q: Why does WCAG 2.2 accessibility matter for business revenue, not just legal risk?
A: Usability research consistently finds that most disabled users abandon sites they can’t use, and roughly 1 in 4 US adults lives with a disability – making inaccessible design a direct driver of lost conversions, not only a lawsuit risk.
Q: What does “shift-left” mean in accessibility development?
A: It means building accessibility checks into design systems and code editors so issues like focus traps or missing labels are caught during development, before they ever reach production.
Source: https://wcagpros.com/wcag-guidelines/accessibility-solutions-ultimate-guide-2026/
This article was researched and written with AI assistance, then reviewed for accuracy and quality. Riya Shah uses AI tools to help produce content faster while maintaining editorial standards.
Need help with your web project?
From one-day launches to full-scale builds, DRS Web Development delivers modern, fast websites.
