Accessibility Compliance Research: What WCAG, the ADA, and the European Accessibility Act Require You to Test

The short answer

No accessibility law in force today requires you to test with disabled users — and that is exactly why conformance audits keep passing products that disabled people cannot use.

Every current regime (the European Accessibility Act, ADA Title II, Section 504, Section 508) points at the same technical target: the Web Content Accessibility Guidelines, at Level AA. WCAG is a checklist of testable success criteria. It is excellent at catching missing alt text, insufficient contrast, and unlabelled form fields. It was never designed to tell you whether a screen reader user can actually complete your checkout.

The evidence on that gap is unusually clean. In a study of 32 blind users across 16 websites, researchers logged 1,383 instances of real user problems — and only 50.4% of them mapped to any WCAG 2.0 success criterion. Roughly half the barriers people actually hit were invisible to the standard. The W3C's own Web Accessibility Initiative says the same thing in plainer language: evaluating with users with disabilities identifies usability issues that conformance evaluation alone does not discover.

So the compliance answer and the research answer are two different jobs. This guide covers both: what each regime legally obliges you to do, and what user research you should run on top of it.

The 2026 deadline reset most guidance has not caught up with

Two US deadlines moved in 2026. A great deal of published advice — and a fair number of internal compliance trackers — still cite the old dates.

• ADA Title II. The DOJ's 2024 rule set WCAG 2.1 Level AA as the standard for state and local government web content and mobile apps. In April 2026 the DOJ issued an interim final rule pushing both compliance dates back one year: 26 April 2027 for public entities serving populations of 50,000 or more, and 26 April 2028 for smaller entities and special district governments.
• Section 504 (HHS). The HHS Office for Civil Rights followed on 7 May 2026 — four days before the original deadline — with its own interim final rule. Recipients of HHS federal financial assistance with 15 or more employees now have until 11 May 2027; those with fewer than 15 employees have until 10 May 2028. The standard is still WCAG 2.1 Level AA, and the rule reaches hospitals, health plans, digital health companies, and clinical research organisations.

Two cautions. First, the extensions delay the technical conformance dates only. They do not suspend the underlying nondiscrimination and effective-communication duties, which have supported accessibility claims for years without any technical standard attached. Private plaintiffs can and do sue during the extension window. Second, litigation volume is not slowing: UsableNet's tracking put 2025 at roughly 5,000 digital accessibility lawsuits, with more than 1,400 filed against companies that had already been sued once before.

The four regimes at a glance

A note on version drift that trips up EU teams: the EAA does not currently mandate WCAG 2.2. The harmonised standard cited in the Official Journal is EN 301 549 v3.2.1, which incorporates WCAG 2.1 Level AA. Version 4.1.1, which brings in WCAG 2.2 Level AA and its six additional success criteria, is expected to be referenced in the Official Journal around late 2026. Building to 2.2 now is sensible future-proofing, not a current legal requirement — and anyone telling you 2.2 is mandatory in the EU today is ahead of the citation.

The other EAA subtlety: EN 301 549 is broader than WCAG. It covers hardware, mobile apps, documentation, video players, and third-party content embedded in your service. A WCAG-only audit does not fully answer the EAA.

Conformance evidence vs. research evidence

Procurement and legal will ask you for conformance artefacts. Product will ask you whether the thing works. Keep the two straight:

Conformance artefacts — an accessibility audit against WCAG 2.1 AA, an Accessibility Conformance Report (usually authored on the VPAT template), and a documented remediation plan with dates. These are what you hand to a buyer's security and legal review, and what you request from every vendor you buy.

Research evidence — task-based sessions with disabled participants using their own assistive technology, on their own devices, with their own settings. This is what tells you the checkout is completable. It is not a substitute for the audit, and the audit is not a substitute for it.

The failure mode is treating the ACR as the finish line. A product can be fully conformant and still strand a user, because WCAG cannot express "the error message is technically announced but appears 40 seconds after the field it refers to."

How to run accessibility research that actually finds barriers

1. Recruit for assistive technology, not for diagnosis. The useful screening variable is the technology stack and how fluently the person uses it — JAWS, NVDA, VoiceOver, Dragon, switch access, screen magnification, high-contrast modes. "Has a visual impairment" is too coarse to plan a session around. Structured screener questions do this cleanly: use single_choice for primary assistive technology, multiple_choice for the full stack, and scale for self-rated proficiency.

2. Never make the research method itself a barrier. This is the most common own-goal in accessibility research. Scheduled video calls with screen sharing, unfamiliar moderation software, and "can you install this plugin" all add access friction that has nothing to do with your product. If a participant spends the first ten minutes fighting your research tool, you have measured your research tool.

3. Let participants choose their modality. Some people are far faster typing with a screen reader than speaking; others are the reverse. Forcing one channel biases who can take part and how much they say.

4. Test tasks, not pages. "Find and change your billing address" surfaces barriers that a page-by-page audit sweep will not. Sequence matters — most real barriers appear at handoffs between steps.

5. Budget properly. Assistive technology users routinely take longer on tasks. Sessions run long, and incentives should reflect the expertise participants bring.

6. Log every barrier against both frames. For each problem, record the task, the assistive technology, the WCAG success criterion if one applies — and mark the ones where none does. That "no matching criterion" column is the most valuable output of the whole study, because it is the part your audit will never produce.

Where Koji fits

Koji runs AI-moderated interviews over a link. Participants open it when they want, on their own device, with their own assistive technology already configured — there is nothing to install, no meeting to join, no screen to share, and no moderator waiting while someone gets set up. For accessibility research specifically, that removes the exact friction that suppresses participation.

Participants can respond by text or by voice, and Koji's AI interviewer asks follow-up questions either way — so when someone says a flow was "confusing", the AI probes for what specifically broke, in the moment, rather than leaving you a one-line note to chase later. Because sessions are asynchronous, you are not constrained to the handful of slots a moderator can run in a day, which matters when your recruiting pool is narrower than usual.

Koji's six structured question types — open_ended, scale, single_choice, multiple_choice, ranking, and yes_no — let you carry a quantitative spine through the study (task success, severity ratings, assistive technology used) while the AI handles the qualitative probing. Reports aggregate both automatically, so severity distributions and the verbatim explanation of each barrier land in the same place.

One thing to do regardless of platform, including this one: ask your research vendor for its own Accessibility Conformance Report. A research tool that is not itself accessible cannot credibly collect accessibility feedback. Treat that request the same way you treat a DPA — a standard, unremarkable part of vendor review.

Common mistakes

• Treating the deadline extensions as a pause. The nondiscrimination duty never moved, and neither did the litigation trend.
• Auditing to WCAG 2.2 and assuming the EAA is satisfied. EN 301 549 covers more than web content; check the full standard against your product surfaces.
• Recruiting one blind participant and calling it accessibility research. Screen reader users are not a proxy for cognitive, motor, or low-vision users, whose barriers differ completely.
• Running the study through inaccessible research software. You will get a clean-looking dataset from the subset of people who could get through your tooling.
• Filing barriers only against WCAG criteria. The uncategorisable half is where the real product work is.

Frequently asked questions

Does WCAG conformance make me legally compliant? It makes you conformant to the technical standard each of these regimes cites, which is the bulk of what regulators ask for. It does not discharge broader nondiscrimination and effective-communication duties, and it does not guarantee a disabled user can complete your tasks.

Do the laws require testing with disabled users? No current regime mandates it as a compliance step. It is nonetheless the only method that surfaces the roughly half of real barriers that WCAG success criteria do not describe, and regulators and courts look favourably on documented user involvement.

Which WCAG version applies to the European Accessibility Act right now? EN 301 549 v3.2.1, incorporating WCAG 2.1 Level AA, is the harmonised standard currently cited. Version 4.1.1 with WCAG 2.2 Level AA is expected to be cited around late 2026.

Did the US accessibility deadlines really move? Yes. DOJ issued an interim final rule in April 2026 moving ADA Title II to 26 April 2027 and 26 April 2028; HHS issued its own on 7 May 2026 moving Section 504 to 11 May 2027 and 10 May 2028. Both kept WCAG 2.1 Level AA.

How many accessibility research participants do I need? Plan per assistive technology group rather than in aggregate. Five to eight participants within a single technology profile will surface most severe barriers for that profile; a study spanning screen reader, magnification, voice control, and cognitive accessibility needs that depth in each.

What is a VPAT, and do I need one? A VPAT is the template; the completed document is an Accessibility Conformance Report. If you sell to government, education, healthcare, or large enterprises, expect to be asked for one — and expect to ask your own vendors for theirs.

Related Resources

• Structured Questions Guide — the six question types, and how to use them for screeners and severity ratings
• Accessibility Research Guide — the methods side: how to include users with disabilities in your studies
• Research Ethics and Informed Consent — consent practice for studies involving disability data
• Trauma-Informed User Research — adjacent guidance for sensitive-topic and vulnerable-participant studies
• Research Screener Questions — writing screeners that find the right assistive technology profiles
• Enterprise Security for AI Research Platforms — the vendor-review companion to requesting an ACR
• GDPR-Compliant AI User Research — handling the health and disability data these studies touch