ADA Website Accessibility Statement: What It Is, Who Needs One, and How to Get It Free

ADA web accessibility lawsuits hit 4,605 filings in 2023 — a record. More than 77% of those cases targeted companies with fewer than 500 employees. The plaintiffs' bar has gotten very good at identifying non-compliant websites, and the easiest target is a business that has done nothing at all: no accessibility work, no testing, and no accessibility statement.

An accessibility statement doesn't make your website accessible by itself. But it does several things that matter legally: it establishes that you're aware of your obligations, it shows good faith effort, it gives users with disabilities a way to contact you when they hit barriers, and in some jurisdictions it is itself a legal requirement, not just a best practice.

This guide covers what an accessibility statement actually is, who is legally required to have one, what WCAG 2.2 requires (and how it differs from 2.1), exactly what your statement must contain, a real example of a compliant statement, and how to generate one free in about 60 seconds.

What Is a Website Accessibility Statement?

An accessibility statement is a public declaration on your website that communicates four core things to users with disabilities. First, your commitment to digital accessibility as a policy matter — that you take it seriously and are actively working toward it. Second, your current conformance status with WCAG standards, stated clearly: fully conformant, partially conformant, or non-conformant, along with the specific standard and version. Third, any known limitations in your current accessibility implementation — pages or features that don't yet meet the standard, with honest explanation of what the issue is. Fourth, how users can contact you to report an accessibility barrier they've encountered or request an alternative format of content they cannot access.

Think of it as the intersection of a compliance document and a service commitment. It tells users with disabilities what they can realistically expect when using your website, and it tells them what to do when your site fails them. That last part matters enormously: for many users relying on screen readers or other assistive technology, knowing there's a working contact channel for accessibility issues is the difference between your site being usable and being a dead end.

Unlike a privacy policy or terms of service, an accessibility statement is also a living document. It should reflect where you actually are — not where you plan to be, and not where a competitor is. If your site has known issues with keyboard navigation on the checkout page, your statement should say so. That honesty is not an admission of liability — it's the entire point of the document.

The Legal Landscape: Who Is Actually Required to Have One?

The honest answer is: it depends heavily on your jurisdiction, the nature of your organization, and the size of your business. Here's what the law actually says in each major region.

United States: ADA Title III

The Americans with Disabilities Act Title III prohibits discrimination by places of public accommodation. Originally written for physical spaces, federal courts have consistently extended this to websites. The legal theory: if you operate a business that serves the public and your website is inaccessible to people with disabilities, you are discriminating against them in the same way a business with no accessible entrance discriminates against wheelchair users.

In March 2024, the Department of Justice issued a final rule under Title II of the ADA specifically requiring state and local government websites and mobile apps to conform to WCAG 2.1 Level AA. This is the first time the DOJ has codified a specific technical standard, and it signals where private sector enforcement is heading. Title II applies to government entities; Title III applies to private businesses — and litigation under Title III has been aggressive.

The numbers are striking. ADA web accessibility lawsuit filings reached 4,605 in 2023, up from 2,352 in 2018. Companies like Domino's Pizza, Netflix, and Harvard University have all faced ADA web accessibility claims. Domino's case went to the US Supreme Court, which declined to hear it, leaving lower court rulings intact. Small businesses are not insulated: over 77% of 2023 filings targeted companies with fewer than 500 employees, because they're easier targets with less legal budget to defend a case.

A published accessibility statement is not a legal shield on its own, but it is one component of a defensible posture. It shows awareness, effort, and a functioning feedback mechanism — all of which matter if you ever face a complaint or lawsuit.

EU: Web Accessibility Directive

The EU Web Accessibility Directive (Directive 2016/2102) is substantially more explicit than US law about the accessibility statement requirement. It requires all public sector bodies in EU member states to publish an accessibility statement that follows a specific template format defined by the European Commission. The statement must include the conformance status, any exceptions with justification, and an enforcement procedure.

The directive was originally scoped to public sector organizations. However, the European Accessibility Act (EAA), which member states were required to implement by June 2022 with enforcement beginning in June 2025, extends accessibility obligations to private sector companies offering services such as e-commerce, banking, transport booking, and digital communications to consumers. While the EAA doesn't mandate the same government-style accessibility statement format for private entities, publishing one that follows the public sector template is the practical way to demonstrate compliance.

If you serve EU customers and fall within the scope of the EAA, you need an accessibility statement. Period.

UK: PSBAR 2018

The Public Sector Bodies Accessibility Regulations 2018 (PSBAR) implement the EU directive in UK law and remain in force post-Brexit. All UK public sector websites and mobile apps — central government, local councils, NHS trusts, universities, and similar bodies — are required to publish an accessibility statement. The Government Digital Service (GDS) provides the official template, and the statement must be published on a specific page accessible from every page of the site via the footer.

Private sector organisations in the UK are not currently mandated to publish an accessibility statement under PSBAR, but the UK Equality Act 2010 creates a duty to make "reasonable adjustments" for disabled users of services — and an accessibility statement with a working contact mechanism is part of demonstrating that duty is being taken seriously.

Canada: AODA

Ontario's Accessibility for Ontarians with Disabilities Act (AODA) applies to public and private sector organizations in Ontario with one or more employees. The Integrated Accessibility Standards Regulation under AODA requires organisations to make their websites conform to WCAG 2.0 Level AA (with certain exceptions), and to have a policy on accessibility. Federal organizations across Canada fall under the Accessible Canada Act. If your business operates in Ontario or serves the Canadian federal government, an accessibility statement — particularly one that describes your AODA compliance status — is part of meeting those obligations.

What WCAG 2.2 Actually Requires (vs 2.1)

WCAG — the Web Content Accessibility Guidelines — is published by the W3C Web Accessibility Initiative. It is not itself a law, but it is the technical standard that nearly every accessibility law worldwide references. Understanding what version applies to you matters because what you claim in your accessibility statement must match the standard you're actually targeting.

WCAG 2.2 was published on October 5, 2023. It is the current version. It builds directly on WCAG 2.1 (published June 2018) — all 2.1 success criteria are included in 2.2 — with nine new criteria added and one removed.

The nine new success criteria in WCAG 2.2 are:

• 2.4.11 Focus Not Obscured (Minimum) — Level AA: A keyboard-focused UI component must not be entirely hidden by author-created content. The most common failure is sticky headers or cookie banners that fully obscure the focused element.
• 2.4.12 Focus Not Obscured (Enhanced) — Level AAA: The focused element must not be partially obscured either. Stricter version of the above.
• 2.4.13 Focus Appearance — Level AAA: The focus indicator must meet minimum size and contrast requirements.
• 2.5.7 Dragging Movements — Level AA: Any functionality that uses a dragging motion must also be achievable with a single pointer action (click/tap). Affects drag-and-drop interfaces.
• 2.5.8 Target Size (Minimum) — Level AA: Interactive targets must be at least 24x24 CSS pixels, unless spacing, inline presentation, or user-agent control applies. Primarily impacts small mobile buttons and links.
• 3.2.6 Consistent Help — Level A: If help mechanisms (chat, contact page, phone number) are present across multiple pages, they must appear in the same relative location on each page.
• 3.3.7 Redundant Entry — Level A: Information previously entered by the user must not be re-requested in the same session unless it's essential (e.g., a password confirmation field).
• 3.3.8 Accessible Authentication (Minimum) — Level AA: Authentication processes must not rely solely on cognitive function tests (like solving a puzzle or remembering a code) unless an alternative is available. Standard CAPTCHA without an audio alternative fails this criterion.
• 3.3.9 Accessible Authentication (Enhanced) — Level AAA: No cognitive function tests permitted in authentication at all, without exception.

WCAG 2.2 also removes criterion 4.1.1 Parsing, which required valid HTML structure. Modern browsers handle malformed HTML gracefully, making the criterion obsolete — any browser that assistive technology runs on will already interpret the DOM correctly regardless of source code validity.

For compliance purposes: WCAG 2.0 (2008) is now considered obsolete. WCAG 2.1 is still widely referenced in older regulations but is the previous generation. WCAG 2.2 Level AA is the target you should state in your accessibility statement for new work in 2026.

What Must Be in Your Accessibility Statement?

Whether you're publishing a statement to meet a legal mandate or as a best practice for a commercial website, the document must contain certain elements to be meaningful. A statement that just says "we care about accessibility" with no specific information is worse than useless — it creates an expectation it can't fulfil.

Here are the required elements:

• Clear statement of commitment to accessibility. A direct affirmation that your organisation is committed to making your website accessible to all users, including those using assistive technology. This sets the tone and establishes intent.
• The standard you're targeting and the specific version. State explicitly: "We aim to conform to WCAG 2.2 Level AA." Do not just say "we follow accessibility guidelines." Vague language is not compliant with EU/UK requirements and is unhelpful to users.
• Conformance status. One of three statements: (a) "Fully conformant" — your site meets all WCAG 2.2 AA criteria with no exceptions; (b) "Partially conformant" — you conform to most criteria but some content does not, which must be listed; (c) "Non-conformant" — you do not conform, with explanation. Most sites should truthfully claim "partially conformant."
• Specific exceptions and known limitations. List the parts of your site that don't yet meet the standard, with an explanation of why and (where possible) what you're doing about it. "Our embedded third-party video player does not currently support captions — we are evaluating alternatives" is an example of an honest, useful limitation disclosure.
• Technical specifications. The browser and operating system combinations tested, and the assistive technologies used in testing (e.g., "Tested with NVDA on Windows 11 with Chrome 124, and VoiceOver on macOS Sonoma with Safari 17"). This tells users what environment your site is known to work in.
• Contact information for accessibility issues. An email address and, where possible, a phone number that users can use to report barriers or request alternative formats of content. This is the mechanism that makes the statement actionable — without it, the statement is a notice with no response path.
• Formal complaints procedure or escalation path. EU and UK regulations explicitly require information about what users can do if they're not satisfied with your response. For EU public sector, this means the relevant enforcement body. For private companies, it means your internal escalation process or the relevant ombudsman.
• Date of the statement or last review. The statement must be dated. EU/UK regulations require the date the statement was last reviewed. Without a date, the statement cannot demonstrate ongoing commitment.
• Alternative contact methods for users who can't use the website at all. A phone number, postal address, or other channel for users who cannot access your site even with assistive technology. If the only way to report an issue is a web form, you have a circular problem.

Recommended optional elements include: a list of known accessibility issues currently being remediated, a timeline for fixing them, and a general feedback mechanism for accessibility suggestions beyond formal complaints.

Real Example of a Compliant Accessibility Statement

Here is what a complete, properly structured accessibility statement looks like for a commercial website. This demonstrates the required sections in their correct order and format:

Common Mistakes to Avoid

Most accessibility statements that exist are bad. Here is what makes them bad — and what you need to do differently.

Claiming the wrong WCAG version. Many sites still cite WCAG 2.0 or 2.1 when 2.2 has been the current standard since October 2023. Using an outdated version reference tells regulators and plaintiffs that you haven't been paying attention. Update your statement to reference WCAG 2.2 for new work.

Claiming "fully conformant" when you haven't tested. This is the most legally dangerous mistake. Stating that your site fully conforms with WCAG 2.2 Level AA when no accessibility audit has been conducted is a false claim that can be disproved with a 10-minute screen reader test. "Partially conformant" is the honest and defensible starting position for most sites.

Providing no contact information for accessibility requests. A statement that describes your commitment to accessibility but gives users no way to report a barrier is purely decorative. The contact channel — a real, monitored email address — is the functional core of the document. Without it, you've made a promise you have no mechanism to keep.

Never updating the statement. An accessibility statement dated 2021 with no review date signals that nothing has changed since 2021 — and courts and regulators will read it that way. Set a calendar reminder to review and re-date your statement at least once a year, and update it whenever you complete new accessibility testing or remediate known issues.

Copying a template without reviewing it against your actual site. Using a generator is fine — it's what you should do. But after generating your statement, you need to replace the placeholder text about known limitations with your site's actual known issues. A statement that lists "PDF documents may not be fully accessible" when you have no PDFs is not an honest statement. Read what you've generated. Make it true for your site.

Burying the statement where no one can find it. A page that exists but isn't linked from anywhere is not accessible. Your accessibility statement must be linked from the footer of every page, at minimum. It should also appear in any legal or information menus. If users can't find it, the contact channel doesn't exist in practice.

How to Add Your Accessibility Statement to Your Website

Create a dedicated page with the URL path /accessibility or /accessibility-statement. Consistency with the URL matters for both SEO and because assistive technology users and accessibility testers know to look there first.

Add a link to the accessibility statement in the footer of every page. The footer is where accessibility testing tools, regulators, and experienced users will look for it. The link text should be either "Accessibility" or "Accessibility Statement" — not "Disability Policy" or anything less standard.

Consider including the link in a "Legal" dropdown in your main navigation alongside your privacy policy and terms of service. This is especially recommended for EU and UK businesses where the statement has regulatory weight.

For specific platforms: on Shopify, add the accessibility statement as a Policy page under Settings > Policies — it will appear in your store footer automatically. On WordPress, create a standard Page and add it to your footer menu via Appearance > Menus. On Squarespace, add a blank page to your Not Linked section and manually add the footer link in Footer > Edit Footer. For custom-built sites, add the footer link in your site-wide footer template component.

The accessibility statement page itself should follow accessibility best practices. Use proper heading structure. Ensure adequate color contrast. Make sure it is keyboard navigable. An accessibility statement that is itself inaccessible is a particularly visible own-goal.

For a full checklist of all the legal pages your site should have — including your accessibility statement, privacy policy, cookie policy, and terms of service — see the website legal compliance checklist.

Generate Your Accessibility Statement Free

The FreeTOS accessibility statement generator produces a complete, ready-to-publish accessibility statement in about 60 seconds. It covers WCAG 2.2 Level AA, lets you select your conformance status (fully conformant / partially conformant / non-conformant), includes fields for your known limitations, and generates properly formatted contact and complaints procedure sections with references to the relevant US, EU, and UK legal frameworks.

There is no account required, no watermark on the output, and no subscription fee. You enter your site name, conformance status, contact details, and any known limitations, and you get a complete, formatted statement you can paste directly into your CMS.

If you're building out your website's legal documentation more broadly, you may also need a privacy policy and — particularly if you're serving EU users — a cookie policy. The cookie banner and cookie policy are separate EU requirements that apply alongside the Web Accessibility Directive. You can generate all three documents free on FreeTOS without creating an account.

Frequently Asked Questions