Image description: Layered legislative documents and a magnifying glass on cream paper, photographed top-down, signalling the routing-to-specifics function of an umbrella regulation primer.
Reading Time: 11 minutes
”Accessibility compliance” is one of those phrases that everyone uses and almost no one defines the same way. A general counsel hears it as exposure under the Americans with Disabilities Act. A procurement officer in Berlin hears it as a clause referencing EN 301 549. An engineering lead hears it as a Lighthouse score. A product manager hears it as a vendor’s monitoring dashboard. They are all, in a sense, correct — and none is talking about quite the same thing.
This article is the umbrella. It unpacks what the term means across three layers — technical, legal, and procedural — explains the most important distinction in the field (compliance is not the same thing as accessibility), and then routes you to the dossier that matches your jurisdiction. If you came in searching “accessibility compliance” because someone above you in the org chart asked whether the company is, you are in the right place. We will give you the map you need to answer that yourself, plus the link to the free WCAG 2.2 scanner for a baseline by the end of the afternoon.
Compliance is not the same thing as accessibility
The single most useful distinction in this field, and the one most often skipped over in vendor pitches, is the gap between compliance and accessibility.
Compliance is a legal and audit posture. It is the answer to the question “can we demonstrate, on paper, that we meet the standard the regulator or the contract has named?” It is satisfied by passing scans, published accessibility statements, conformance reports, and procurement attestations. Compliance is a state you can be in or out of at a moment in time, and it is the state lawyers and auditors care about.
Accessibility is the answer to a different question: “can a person with a disability actually use this product to do the thing it was built for?” It is satisfied by a screen-reader user completing the checkout, a keyboard-only user navigating the dashboard, a deaf user understanding the video. Accessibility is a property of the lived experience, not the audit file.
The two are correlated but not identical. A site can pass an automated WCAG 2.2 AA scan, publish a clean accessibility statement, ship a VPAT, and still be unusable with VoiceOver because every custom dropdown swallows focus. Another site can have a few hundred minor scan failures and still be usable end-to-end by every assistive-tech user in the room. Conformance is necessary but not sufficient. Treating the audit as a proxy for the experience is the most common — and most expensive — mistake in this space.
Compliance is not a one-time audit
The second crucial distinction. An audit that passes on Monday does not survive a deploy on Tuesday. Marketing sites push twice a week; product surfaces push twenty times a day. Every push is an opportunity to break a label, lose a focus ring, or ship a component that announces itself as a div to NVDA.
Compliance, properly understood, is a posture maintained through continuous monitoring and a culture of remediation — not a snapshot captured in a PDF dated nine months ago. The PDF is evidence. The monitoring is the thing being evidenced. The deepest pitfall in this space is treating compliance as a project rather than as an operating mode.
Every serious accessibility programme has the same shape regardless of jurisdiction: an automated monitoring layer that catches regressions on every deploy, a periodic manual audit layer that catches what automation misses, and a published statement that the regulator can read. Lose any of the three and the posture decays.
The three layers of accessibility compliance
It helps to think of accessibility compliance as three stacked layers. A given organisation has to satisfy each of them, and the requirements at each layer come from a different source.
Layer 1 — Technical standards. What your site, app, or product has to look like at the code level. This is the layer the W3C and the European standards bodies own. The dominant standard is WCAG, currently at version 2.2. Most regulators reference Level AA. Other technical standards layer on top: ARIA for rich UI, EN 301 549 for the European procurement and EAA context, Section 508 for US federal procurement, EPUB Accessibility 1.1 for ebooks, PDF/UA for documents. WCAG 2.2 AA is the centre of the spec map; the others extend or instantiate it.
Layer 2 — Regional regulation. What the law in your jurisdiction actually requires. The ADA, the European Accessibility Act, the UK Equality Act, the Accessible Canada Act, Italy’s Stanca Act, Germany’s BFSG. The technical standard from Layer 1 is almost always pulled in by reference — the ADA Title II rule names WCAG 2.1 AA; the EAA references the harmonised standard EN 301 549, which references WCAG 2.1 AA. The law is what you are accountable to; the standard is how the law decides whether you met the bar.
Layer 3 — Procurement and sector mandates. Where the contract pushes beyond the legal floor. EU public-sector procurement uses EN 301 549 as the floor for any IT purchase. US federal procurement uses Section 508, which now harmonises with WCAG 2.1 AA. Financial-sector and healthcare regulators sometimes add their own overlays. If you are selling into a public-sector buyer, the contract is usually a stricter ceiling than the law.
Most organisations have to satisfy all three layers simultaneously.
The country map — where you are determines what applies
This is the routing section. Find the row that matches the jurisdiction you operate in, then click through to the dossier.
United States
The Americans with Disabilities Act is the spine of US accessibility law. Title II governs state and local government and got its first explicit web rule in April 2024, naming WCAG 2.1 AA. Title III governs private places of public accommodation and is enforced primarily through private litigation — roughly 4,300 federal website cases in 2024. See the ADA Title III dossier and the US regulations hub for Section 508 and state statutes.
European Union
The European Accessibility Act (Directive 2019/882) became enforceable across the 27 member states on 28 June 2025, applying to a defined list of consumer products and services — ecommerce, banking, ebooks, ticketing, transport. The Web Accessibility Directive (2016/2102) covers public-sector bodies separately. Both reference the harmonised standard EN 301 549, which references WCAG 2.1 AA. See the European Accessibility Act guide.
Germany
The Barrierefreiheitsstärkungsgesetz (BFSG) is Germany’s transposition of the EAA and has applied to in-scope private-sector services since 28 June 2025. BITV 2.0 governs the public sector. Enforcement runs through market-surveillance authorities at the Länder level. See the Germany dossier.
United Kingdom
The Equality Act 2010 imposes a general duty not to discriminate, interpreted by courts to extend to digital services. The Public Sector Bodies Accessibility Regulations 2018 layer a specific WCAG 2.1 AA requirement onto public bodies. The UK did not transpose the EAA; private-sector exposure runs through the Equality Act. See the United Kingdom dossier.
Italy
The Stanca Act (Law 4/2004) predates EAA harmonisation and applies to public bodies and a defined list of private-sector entities including financial services and large ecommerce. EAA transposition extends scope further. See the Italy dossier.
Canada
The Accessible Canada Act covers federally regulated entities including banks, telecoms, and federal departments; the AODA covers Ontario provincially, with full private-sector application from 2025. See the Canada dossier.
Australia
The Disability Discrimination Act 1992 is the statutory baseline, interpreted to cover digital services since the 2000 Maguire case. The Australian Human Rights Commission publishes WCAG-aligned guidance. See the Australia dossier.
Everywhere else
Disability World maintains country dossiers across 55 jurisdictions including Japan, India, Brazil, South Korea, Israel, South Africa, Mexico, the GCC states, and the rest of the EU and ASEAN.
What WCAG 2.2 actually requires
WCAG — the Web Content Accessibility Guidelines — is the technical reference almost every other instrument in this stack defers to. Version 2.2 was published by the W3C in October 2023 and adds nine new success criteria to the 2.1 baseline. Three conformance levels exist: Level A (the bare minimum), Level AA (the working benchmark referenced by every major regulator), and Level AAA (aspirational, not a regulatory floor anywhere).
WCAG is organised around four principles, the POUR acronym. Content must be Perceivable (available to senses the user has — text alternatives for images, captions for audio, sufficient colour contrast), Operable (the interface can be driven — keyboard-accessible, no seizure-inducing flashing, enough time to read), Understandable (the content and the interface are predictable — readable text, consistent navigation, error prevention on form input), and Robust (it works with the assistive technology the user actually has — parseable markup, name-role-value exposed on every interactive element).
The 2.2 specification has 86 numbered success criteria across the three levels. Level AA is the working target for compliance purposes; pulling Level A only is insufficient under every regulatory regime that names a level. The full reference, organised criterion by criterion with examples and common failure patterns, lives at the WCAG 2.2 success criteria page in our toolkit.
Next-step CTAs — three concrete actions
Compliance is a posture, not a project, but you have to start somewhere. The right next action depends on where you are in the journey.
”I have no idea where we stand” — start with a baseline
Run the free WCAG 2.2 scanner on your top ten pages — homepage, login, checkout, dashboard, two key conversion flows, the accessibility statement page itself if you have one. A scan will not tell you the full picture (see the section on compliance versus accessibility above), but it will tell you whether you have ten issues or ten thousand, which is the first thing you need to know. Then read the regulation dossier for your jurisdiction from the country map in the previous section.
”We have a scanner — what’s next?” — commission a manual audit
Automated scans catch roughly a third of issues. The rest require manual review. Commission a manual audit by testers with disabilities — screen-reader users for the screen-reader paths, keyboard-only users for the keyboard paths, low-vision users for the visual paths. A first manual audit on a mid-sized application typically takes two to four weeks and surfaces the issue classes automation cannot see: ambiguous link text in context, focus order that is technically correct but cognitively wrong, custom widgets that work but feel wrong.
”We’re operationalising compliance long-term” — choose a monitoring platform
This is the stage at which monitoring matters. Continuous monitoring catches regressions on every deploy, surfaces drift between manual audits, and produces the evidence trail that satisfies a regulator asking how you maintain the posture between formal reports. The full comparative review of the platforms in this category lives in the monitoring buyer’s guide — including axe Monitor, Siteimprove, Level Access and Qualibooth, which are the four platforms most often shortlisted for the monitoring-plus-manual-audit-handoff combination. The buyer’s guide compares them on coverage, false-positive rates, manual-audit workflow, integration surface, and price. Read that next; do not pick a platform from a single page.
Frequently asked questions
What does accessibility compliance mean?
Accessibility compliance is the legal and audit posture of meeting whichever standard a regulator, contract, or industry body has named as authoritative for your situation. In practice it usually means three things at once: meeting a technical standard such as WCAG 2.2 Level AA, satisfying a regional law such as the ADA or the European Accessibility Act, and producing process artefacts such as a published accessibility statement. None of these on their own equals accessibility for real users — they are the audit-side picture.
Is WCAG the same as the ADA?
No. WCAG is a technical standard published by the W3C; the ADA is a US civil rights law. The two are linked because US courts and the Department of Justice have treated WCAG 2.1 Level AA as the working benchmark for what counts as an accessible website under Title II and Title III, but the ADA itself never names WCAG in its statutory text. EN 301 549 plays the same bridging role in the EU.
Is my website legally required to be accessible?
Almost certainly, yes, if you operate in the US, the EU, the UK, Canada, Australia, or any of the 50-plus jurisdictions with a disability-rights statute and a working enforcement record. The exact obligation depends on whether you are a public-sector body, a commercial business of a certain size, or a vendor to government. The country map in this article points to the dossier for your jurisdiction.
What WCAG level do I need — A, AA, or AAA?
AA is the working answer for almost every regulator. The ADA Title II 2024 rule names WCAG 2.1 Level AA. The European Accessibility Act and EN 301 549 reference WCAG 2.1 AA. The UK Public Sector Bodies regulations reference 2.1 AA. AAA is aspirational and is not a regulatory floor anywhere. Level A alone is insufficient under every major regime.
How is accessibility compliance enforced in the US?
Through three channels. Department of Justice rulemaking and enforcement under Title II and Title III of the ADA. Private litigation under Title III, which produced roughly 4,300 federal website cases in 2024. And state-level demand letters under New York, California, and similar consumer-protection regimes. There is no single federal accessibility regulator equivalent to the EU’s market-surveillance authorities.
Does the EAA apply to non-EU companies?
Yes, where they place products or services on the EU market. The European Accessibility Act applies to any economic operator selling covered products or services to consumers in any of the 27 member states, regardless of where the operator is established. A US ecommerce site shipping to Germany is in scope for the German transposition, the BFSG.
Is automated scanning enough to be compliant?
No. Automated scanners catch roughly 30 to 40 percent of WCAG issues under generous assumptions — colour contrast, missing alt text, missing form labels, document structure. They cannot judge whether alt text is accurate, whether a flow is usable by a screen-reader user, or whether a custom widget exposes the right roles and states. A defensible compliance posture combines automated monitoring with periodic manual audits by testers with disabilities.
In closing
Accessibility compliance is a posture, not a project. The audit on the wall is evidence of the posture; the monitoring, the manual audits, the remediation culture, and the published statement are the posture itself. Lose the posture and the audit goes stale within a quarter.
If you are starting from zero, run the free WCAG 2.2 scanner, read the regulation dossier for your jurisdiction from the country map above, and book a manual audit. If you are operationalising for the long term, read the monitoring buyer’s guide. The umbrella is over. Pick the door.