Web accessibility compliance: how to prove your site meets the law
Digital presences are no longer lightly regulated corners of a business. They are storefronts, banking counters, ticket offices and contract desks, and the law now treats them that way. Across the European Union, the United Kingdom, North America and Australia, a wave of legislation has moved web accessibility from a design preference to a binding obligation, with deadlines, supervisory authorities and penalties attached. The European Accessibility Act became applicable on 28 June 2025. Lawsuits in the United States crossed 5,000 in a single year. The rules are clear about one thing in particular: you must not only be accessible, you must be able to show it.
That second part is where most organizations are exposed. When a complaint arrives, the practical question is rarely "is the site accessible today." It is "can you prove the site was accessible on the date you claimed it was." A scanner can tell you the present state. It cannot freeze the past. So web accessibility compliance is really two problems wearing one name: meeting the technical standard, and holding defensible, dated evidence that you met it. This article covers the laws country by country, the standard they all converge on, and the piece almost no one talks about: how to create a certified, timestamped record of your site's accessibility state at a specific moment.
Web accessibility compliance refers to designing and operating a website so that people with disabilities can perceive, navigate and interact with it, in line with a recognized technical standard. In practice that standard is the Web Content Accessibility Guidelines (WCAG), typically Level AA. No statute spells WCAG into its text as the literal rule, yet courts, regulators and procurement bodies treat WCAG 2.1 and 2.2 Level AA as the working proof of conformity. According to the WebAIM Million 2026 analysis, 95.9% of the top one million home pages had detectable WCAG failures, averaging 56.1 errors per page. Compliance, then, is both a technical target and an evidentiary claim you may one day have to defend.
Why accessibility compliance is now a legal and business risk
Accessibility has shifted from an ethical aspiration to an enforceable duty backed by fines and litigation. New transposition deadlines, active supervisory authorities and a steady rise in lawsuits mean an inaccessible site is now a measurable financial and legal liability, not a reputational footnote. The cost shows up as settlements, statutory penalties, remediation under deadline pressure, and the legal expense of defending a claim you cannot document.
From "nice to have" to legal obligation
For two decades, accessibility lived in the realm of good intentions and procurement checklists. That era is over. The European Accessibility Act now binds private companies offering consumer products and services, German firms face the BFSG, Italian businesses fall under the transposition of the EAA, and public bodies across the UK, US, Canada and Australia have long operated under binding accessibility duties. The common thread is that accessibility is no longer optional for whole categories of business, and the obligation increasingly applies to the private sector, not just government.
What changed is the legal architecture around digital accessibility. Where older laws relied on general anti-discrimination principles applied to websites after the fact, the newer generation names digital services explicitly, sets a technical standard, and attaches a date. That precision cuts both ways. It tells you exactly what to do, and it gives a regulator or a claimant exactly what to measure you against.
Lawsuits, fines and the burden of proof
The financial exposure is concrete and growing. In the United States, more than 5,000 ADA lawsuits over digital accessibility were filed in 2025, and roughly 70% of them targeted e-commerce, according to UsableNet's litigation tracking. In Europe, national penalty regimes range from administrative fines into the tens of thousands of euros to, in some jurisdictions, a percentage of turnover. The pattern is consistent across borders: the law expects you to publish or demonstrate conformity, and failure carries a price.
Beyond private settlements, the exposure can be statutory. In the United States the Department of Justice can impose civil penalties under Title III of up to $75,000 for a first violation and $150,000 for each subsequent violation, figures now inflation-adjusted to roughly $92,383 and $184,767. Small and mid-sized businesses are the most frequent targets, and a demand letter rarely arrives with advance warning, which is why being able to produce certified digital evidence for litigation about your site's past state is worth more than any single scan.
When an accessibility complaint is filed, the burden of showing the site was conform on a given date typically falls on the owner, not the complainant. This is the quiet pivot point of every accessibility dispute. A demand letter alleging an inaccessible checkout does not ask whether you can fix it now; it asks what state the page was in on the date in question. Settlement values for web accessibility claims commonly fall in the $5,000 to $25,000 range, and defense costs can exceed the settlement itself. Without a dated, independent record of the site's state, an organization is left arguing from memory and server logs, which is a weak position when the other side has screenshots. Evidence, not just conformity, decides these cases.
Web accessibility laws by country: a global overview
Most major economies now impose web accessibility obligations, and despite different legal traditions they converge on the same technical standard. The table below maps the principal laws, who they bind, the standard they reference and the key deadlines or sanctions. Read it as a compliance map: the duties differ in scope and penalty, but the conformity target is remarkably uniform.
| Country / region | Law | Applies to | Standard | Key deadlines / sanctions |
|---|---|---|---|---|
| European Union | European Accessibility Act (Dir. 2019/882) | Consumer products and services: e-commerce, banking, e-books, e-readers, self-service terminals, e-communications | EN 301 549 / WCAG 2.1 AA | Applicable 28 Jun 2025; micro-enterprise service exemption (<10 staff and <=EUR 2M); national penalties "effective, proportionate, dissuasive" |
| EU (technical) | EN 301 549 (ETSI) | Backbone standard referenced by EU law | Incorporates WCAG 2.1 A/AA, extends to software, hardware, docs | Harmonized V3.2.1 (2021); draft V4.1.0 moving toward WCAG 2.2 AA |
| Germany | BFSG (Barrierefreiheitsstärkungsgesetz) | Private firms within EAA scope | EN 301 549 / WCAG 2.1 AA | Obligations from 28 Jun 2025; fines up to EUR 100,000 (§37) |
| Italy | Legge Stanca (L. 4/2004) + D.Lgs. 82/2022 | Public sector (Stanca) + private sector (EAA transposition) | EN 301 549 / WCAG 2.1 AA | Private obligations from 28 Jun 2025; AgID supervises; administrative fines |
| France | RGAA + Art. 47 Loi 2005-102 | Public online services + private firms with French turnover >EUR 250M; scope | EN 301 549 / WCAG 2.1 AA | Accessibility declaration + 3-year plan + homepage notice; fines up to EUR 25,000 (renewable); EAA regime up to EUR 50,000 per service (ARCOM) |
| United Kingdom | Equality Act 2010 + PSBAR 2018 | Service providers (reasonable adjustments) + public sector (statement mandatory) | WCAG 2.2 AA via EN 301 549 | Accessibility statement required; EHRC enforces; no fixed fine (court-determined) |
| United States | ADA Title III + Section 508 + DOJ Title II rule | Public accommodations (ADA), federal ICT (508), state/local gov (Title II) | WCAG 2.1 AA (de facto for ADA; explicit for 508/Title II) | Title II deadlines extended one year (interim rule 20 Apr 2026): 50,000+ population now 26 Apr 2027, smaller entities 26 Apr 2028; ADA remedies = injunctive relief + legal costs |
| Canada | Accessible Canada Act + AODA (Ontario) | Federally regulated entities (ACA) + Ontario organizations (AODA) | WCAG 2.0 AA | ACA fines up to CAD 250,000; barrier-free Canada target 1 Jan 2040; AODA penalties up to CAD 100,000/day for corporations |
| Australia | Disability Discrimination Act 1992 | Websites via case law (Maguire v SOCOG, 2000); gov policy | WCAG 2.1 AA min (2.2 AA for new gov work, from 1 Jan 2025) | AHRC handles complaints; no fixed fine, remedies via Federal Court |
European Union: the European Accessibility Act (EAA) and EN 301 549
The European Accessibility Act is the EU's first horizontal accessibility law for the private sector, and it became applicable on 28 June 2025. The EAA, Directive (EU) 2019/882, sets common accessibility requirements for a defined list of consumer products and services: e-commerce, consumer banking, e-books and e-readers, self-service terminals and electronic communications. Microenterprises providing services are exempt, specifically those with fewer than 10 employees and turnover at or below EUR 2 million. Penalties are set nationally and must be effective, proportionate and dissuasive.
The technical backbone is EN 301 549, the harmonized European standard published by ETSI. Its harmonized version V3.2.1 (2021) incorporates WCAG 2.1 Level A and AA and goes further, covering non-web software, hardware and documentation. A draft V4.1.0 is moving the European baseline toward WCAG 2.2 AA. For most web teams the practical instruction is simple: meet WCAG 2.1 AA today and watch EN 301 549 for the 2.2 transition.
Germany: the Barrierefreiheitsstärkungsgesetz (BFSG)
Germany transposed the EAA through the Barrierefreiheitsstärkungsgesetz (BFSG), with obligations applying from 28 June 2025. The BFSG covers the same products and services as the EAA and points to EN 301 549 and WCAG 2.1 AA as the conformity benchmark. Its enforcement teeth are notable: under §37, fines can reach EUR 100,000. German market-surveillance authorities can require corrective action and, where a product or service stays non-conform, withdraw it from the market. For companies selling into Germany, the BFSG raises both the documentation bar and the cost of getting it wrong.
Italy: Legge Stanca and the EAA transposition
Italy operates a two-track system. The Legge Stanca (Law 4/2004) has long governed accessibility in the public sector, while D.Lgs. 82/2022 transposes the EAA for private operators, with obligations applying from 28 June 2025. The supervisory authority is AgID, which oversees conformity and can apply administrative sanctions. The conformity standard, as elsewhere in the EU, is EN 301 549 and WCAG 2.1 AA. Italian businesses within EAA scope must publish an accessibility statement and be ready to demonstrate the technical conformity behind it.
France: RGAA and the loi handicap
France combines a long-standing duty under Article 47 of the loi handicap (Law 2005-102) with its own technical reference, the RGAA. The obligation covers public online services and private companies with French turnover above EUR 250 million. Those in scope must publish an accessibility declaration, maintain a multi-year plan covering three years, and display an accessibility notice on the homepage. Sanctions under the pre-existing regime reach EUR 25,000 and are renewable; under the EAA regime, ARCOM can impose up to EUR 50,000 per service. The EAA rules apply from 28 June 2025, and the conformity reference remains EN 301 549 and WCAG 2.1 AA.
United Kingdom: Equality Act 2010 and PSBAR
The UK approaches accessibility through two instruments. The Equality Act 2010 imposes a duty to make reasonable adjustments, which case law and guidance extend to digital services, while the Public Sector Bodies Accessibility Regulations 2018 (PSBAR) require public sector websites and apps to meet WCAG 2.2 AA via EN 301 549 and to publish an accessibility statement. There is no fixed statutory fine: enforcement runs through the Equality and Human Rights Commission, and remedies in Equality Act claims are determined by the courts. The government guidance makes the accessibility statement a non-negotiable, public artefact.
United States: ADA, Section 508 and WCAG
The US has no single web accessibility regulation for private business, yet WCAG 2.1 AA has become the de facto benchmark in litigation and settlements. The ADA, Title III applies to private "public accommodations," and while it names no technical standard for the web, courts and settlements routinely use WCAG 2.1 AA; remedies center on injunctive relief plus legal costs, with statutory damages available in some states such as under California's Unruh Act. Section 508 requires federal ICT to meet WCAG 2.0 AA. The DOJ's Title II rule of April 2024 sets WCAG 2.1 AA for state and local government; note that an interim final rule of 20 April 2026 extended the deadlines by one year, so entities serving 50,000 or more people now have until 26 April 2027, and smaller entities and special districts until 26 April 2028.
Canada and Australia: ACA, AODA and the DDA
Canada and Australia round out the picture with framework laws plus regional or sectoral rules. The Accessible Canada Act governs federally regulated entities, requires accessibility plans, allows administrative monetary penalties up to CAD 250,000, and aims for a barrier-free Canada by 1 January 2040; Ontario's AODA (O. Reg. 191/11) required applicable sites to meet WCAG 2.0 AA by 1 January 2021, with penalties up to CAD 100,000 per day for corporations. Australia's Disability Discrimination Act 1992 reaches websites through case law (the landmark Maguire v SOCOG decision in 2000), with complaints handled by the AHRC and remedies pursued in the Federal Court; government policy now sets WCAG 2.1 AA as a minimum and WCAG 2.2 AA for new work under the Digital Inclusion Standard from 1 January 2025.
The common denominator: WCAG 2.1 and 2.2 Level AA
Strip away the national differences and one standard remains: WCAG, almost always at Level AA. Every law in the table above either names WCAG directly or reaches it through EN 301 549, which embeds it. That convergence is what makes a global compliance strategy feasible. WCAG 2.1, a W3C Recommendation since 5 June 2018, and WCAG 2.2, a Recommendation since 5 October 2023, are built on four principles known as POUR: content must be Perceivable, Operable, Understandable and Robust. Levels run A, AA and AAA, with AA the legal and procurement target in most jurisdictions. WCAG 2.2 adds nine success criteria and is backward-compatible, so meeting 2.2 AA also satisfies 2.1 AA. For the full picture, the W3C WAI overview is the authoritative reference.
The missing piece: documenting the state of your site over time
Knowing the standard and passing a scan today does not, on its own, protect you. The piece almost every compliance program leaves out is durable, dated evidence: a defensible record of what your site actually looked like and how it behaved at a specific point in time. Scanners and audits answer "is it conform now." They do not answer "can you prove it was conform on the day you said so." That gap is exactly where disputes are won and lost.
How to prove your website's accessibility compliance
You prove web accessibility compliance by pairing the technical standard with dated evidence that you met it, not by relying on a scan alone:
- Run a WCAG 2.2 Level AA audit and remediate the issues it finds.
- Publish an accessibility statement that names the standard and the date.
- Capture a certified, timestamped record of the site's actual state on that date.
- Repeat the capture after every significant change, so you hold a continuous dated trail.
The third step is the one most programs skip, and it is the reason a routine practice of capturing evidence, in effect a way to save a web page as evidence, is what separates a defensible compliance posture from an undocumented claim.
Consider how an accessibility complaint actually unfolds. A user, advocacy group or law firm alleges that a page failed a WCAG criterion on a particular date. By the time the demand letter lands, often months later, the site has changed: new code has shipped, content has been swapped, a third-party widget has quietly updated itself overnight. Your current scan says nothing about the allegation. What matters is the state of the page back then, and most organizations have no trustworthy way to reconstruct it.
Unlike a scan, a certified record proves what a page looked like and when. A WCAG scan is a snapshot of conformity that ages the moment your site changes; it carries no independent proof of date and is trivial to dispute as self-generated. Accessibility law compounds the problem by requiring public proof. Under the EAA, an accessibility statement is a standing obligation for in-scope businesses from 28 June 2025, with the regime extending to further deadlines through 2030. A statement is a claim. The question a regulator or court eventually asks is whether you can substantiate that claim with evidence of the site's actual state on the date you published it. That is a documentation problem, not a scanning one.
Why does a plain screenshot not solve this? Because a screenshot you took yourself proves nothing about when you took it or whether you edited it afterward. Anyone can change a file's date. The same weakness applies to a self-generated PDF audit report: it is your word about your own site. What the burden of proof demands is independence and a verifiable date, the same qualities that make any digital evidence credible. This is the connection to the wider discipline of admissibility of digital evidence: a record is only as strong as your ability to prove it has not been altered since the moment of capture.
How to create certified accessibility evidence with TrueScreen
You create certified accessibility evidence by capturing the exact state of a page, its content, code and rendered appearance, and sealing that capture with a qualified timestamp so the record is independently verifiable and dated. This is the layer that sits alongside your scans and statements: not a test of conformity, but defensible proof of the site's state at a moment you choose.
TrueScreen, the Data Authenticity Platform, produces a dated, independently verifiable record of a site's accessibility state. It does not scan, fix or remediate accessibility, and it is not an overlay; it captures and certifies, using forensic methodology, what was published and when. Each record is sealed with a qualified electronic timestamp issued by a third-party QTSP that TrueScreen integrates via API, which under the eIDAS framework carries a legal presumption as to date and integrity. The result is a certified, timestamped record of a website's accessibility state that an organization can use to support its accessibility statement, its audit trail and, if needed, its legal defence. It is the evidence layer that scanners and audit tools were never designed to provide.
To be precise about the division of labour: WCAG scanners like axe, WAVE or Lighthouse, and the audit services built on them, tell you whether a site meets the standard at a given moment. TrueScreen does not replace them. It captures and certifies the dated, defensible proof of the site's state at that moment, so the audit and the evidence sit side by side. The two are complementary, and a mature compliance program needs both.
Forensic Browser: certified capture of a full audit session
The TrueScreen Forensic Browser is a tool for the forensic capture of an entire browsing session, certifying it as a dated record. As you work through a site, it captures the page, its DOM and source code, HTTP headers, network activity and rendered screenshots, then seals the whole session with a hash and a qualified timestamp. For an accessibility audit this is the natural companion to the scan itself: while the scanner produces findings, the Forensic Browser produces the certified record of exactly what was tested, in what state, on what date. If the audited pages later change, the session remains a fixed, verifiable reference point.
This matters most for the pages that carry legal weight: a checkout flow, an account-creation form, a booking funnel. Capturing them in a single certified session means the evidence covers the user journey, not just an isolated URL, which is closer to how complaints are actually framed.
Browser Extension: on-demand certified evidence while you browse
The Browser Extension provides one-click certified capture of a single page or state, directly in the browser, without interrupting your workflow. Where the Forensic Browser is built for a full audit session, the extension is for the targeted moment: you publish an updated accessibility statement and immediately certify the homepage; a developer ships a fix and you capture the corrected component; a support team documents a page a user reported. Capturing a page with the extension seals its content and code with a qualified timestamp, so each record is independently verifiable and dated. It turns routine compliance moments into a growing, dated evidence trail rather than a set of undocumented claims.
Certified record vs VPAT and the Accessibility Conformance Report (ACR)
A VPAT, and the Accessibility Conformance Report (ACR) it becomes once completed, is a self-asserted document: the vendor or its assessor states how a product measures against WCAG, Section 508 or EN 301 549, marking each criterion as Supports, Partially Supports or Does Not Support. An ACR records a conformance opinion. It does not, on its own, prove what a page actually rendered on a given date. A certified accessibility record answers that second half. Captured with the TrueScreen Forensic Browser, it freezes the page exactly as it was served, its content, code and rendered appearance, and seals that capture with a qualified electronic timestamp issued by a third-party QTSP integrated via API. The two are complementary: the ACR states your conformance position, while the certified record is the dated, independently verifiable evidence that backs it if that position is ever challenged. This pairing matters most in regulated buying, where certified evidence for procurement turns an accessibility claim in a tender into something a buyer can verify.
What a certified accessibility record contains
A certified accessibility record is a sealed bundle of the technical artefacts that together prove a page's state and the date it was captured. The point of certifying all of them, rather than a single screenshot, is that accessibility is determined by code and structure as much as by appearance: the DOM, the headers and the source are where WCAG conformity actually lives. The table below shows what a complete record holds and why each element earns its place.
| Record element | What it captures | Why it matters for accessibility proof |
|---|---|---|
| Rendered screenshots | The visual state of the page as users saw it | Shows visible accessibility features (contrast, focus, layout) on the date |
| DOM and source code | The underlying HTML, ARIA attributes and structure | WCAG conformity lives in the code; proves semantic structure, alt text, roles |
| HTTP headers | Server responses and metadata of the request | Establishes authenticity and context of the capture |
| Network activity | Resources, scripts and third-party widgets loaded | Documents external components that can affect accessibility |
| Cryptographic hash | A unique fingerprint of the captured data | Proves the record has not been altered since capture |
| Qualified timestamp | Date and time sealed by an integrated third-party QTSP | Creates a legal presumption as to when the state existed (eIDAS) |
| Audit metadata | Capture details, environment, identifiers | Supports the chain of custody and reproducibility |
Capturing a page with the TrueScreen Forensic Browser seals its content and code with a qualified timestamp, which is what lets a third party verify the record independently rather than taking your word for it. This is the same principle behind robust digital provenance: the value of the evidence comes from being able to demonstrate, to someone who was not there, both what existed and when.
Picture the concrete case. A retailer publishes its EAA accessibility statement on 28 June 2025. The same day, it uses the Forensic Browser to capture a certified record of the homepage, the checkout and its key product pages. Eighteen months later, a demand letter alleges the checkout was inaccessible. The dated certified record shows the exact state of those pages on the statement date, shifting the dispute from "your word against ours" to documented fact. The scan told the retailer it was conform; the certified record let it prove that it had been.

