Accessibility statement

How to Write an Accessibility Statement for Your Website

Q: Is an accessibility statement legally required?

It depends on where you operate and what kind of site you run. EU public-sector bodies must publish an accessibility statement under the Web Accessibility Directive (Directive 2016/2102); private companies in the EU are not yet legally required to publish one, though the European Accessibility Act (EAA), which applies to many private-sector digital products from 2025, implies documented compliance. In the US, no statute currently requires a statement for private websites, but courts in ADA Title III cases consistently weigh the presence of a statement as evidence of good-faith remediation — making it a meaningful risk-reduction step even where it is not mandatory.

Q: What does 'partially compliant' mean in an accessibility statement?

'Partially compliant' means your site meets most WCAG 2.1 Level AA criteria but has known failures that you have documented and are working to address. This is the honest status for almost every real-world site — the key is to name the specific failures (e.g., 'some older PDFs lack reading-order tags; we are replacing them by Q4 2026') rather than leaving the status vague. 'Fully compliant' should only be used if you have a recent third-party audit confirming it. 'Not compliant' should be used if you have not yet assessed the site or have significant known failures without a remediation plan.

Q: Should I list known accessibility failures in my accessibility statement?

Yes. Disclosing known failures in your accessibility statement is more protective than omitting them. Courts and regulators view honest disclosure combined with a remediation timeline as evidence of good faith. Omitting known failures while claiming 'partially compliant' status creates a credibility problem if a demand letter or complaint cites those exact failures. Name the failure, name the criterion it violates (e.g., WCAG 1.4.3 Color Contrast, Level AA), and include a target resolution date.

Q: Where should I publish my accessibility statement?

Publish it on a dedicated URL — /accessibility or /accessibility-statement — and link to it from the footer of every page. The footer link is important: it signals to users (and to plaintiff attorneys doing preliminary reviews) that the statement exists and is findable. A statement buried in a dropdown menu or not linked from the footer has significantly lower visibility and legal weight than one linked directly in the footer nav.

Q: How often should I update my accessibility statement?

Update it whenever you complete a remediation pass (to move known failures off the list or update their target dates), whenever a major site change introduces new content or functionality, and at minimum once per year. The 'last reviewed' date in the statement is the most-scrutinized field in enforcement actions — an out-of-date statement (more than 12 months) suggests the commitment is performative rather than ongoing.

Q: What should I do when someone contacts me through my accessibility statement?

Respond within a reasonable timeframe — best practice is 48–72 hours. Acknowledge the reported issue, log it, reproduce it if possible, and fix it or add it to your documented known-failures list with a target date. The important thing is to close the loop: reply to the person who reported the issue, tell them what you found, and when it will be addressed. An ignored accessibility contact form is almost as bad as not having one — responsiveness is part of what 'good faith' means in practice.

An accessibility statement is a public page that documents your WCAG compliance commitment, discloses known limitations, and gives users a way to report issues. Courts weigh it as evidence of good faith. Enterprise procurement teams increasingly require one. This guide covers exactly what it must include — and gives you a fill-in template you can publish today.

Not legal advice. This guide explains best practices for accessibility statements based on WCAG guidance and common legal context — it is educational, not legal counsel. If you are responding to a demand letter or formal complaint, consult a qualified attorney.

What it is
When it’s required
7 required elements
Fill-in template
Where to publish
How often to update
Common mistakes
FAQ

What an accessibility statement is

An accessibility statement is a dedicated page on your site that explains three things: (1) what accessibility standard you are targeting, (2) how well you currently meet it, and (3) how users can report accessibility problems they encounter.

It is not a marketing claim (“we care about accessibility”) or a legal disclaimer. It is a technical disclosure document — one that should accurately reflect the real state of your site, including failures you know about.

The difference in legal weight between a vague accessibility pledge and a specific, honest statement with a “last reviewed” date is significant. The pledge is boilerplate; the statement is evidence.

When an accessibility statement is legally required

Required under EU law — public sector: The EU Web Accessibility Directive (2016/2102) requires public-sector bodies in EU member states to publish an accessibility statement in a specific format, monitor compliance, and report to the European Commission. The statement must follow the W3C model and include a formal complaints mechanism.

Implied by the European Accessibility Act (EAA) — private sector: The EAA, which covers many private-sector digital products and services, took effect in EU member states in 2025. While it does not mandate an accessibility statement by name, demonstrating WCAG compliance and having a documented feedback mechanism are practical requirements for compliance.

Not currently mandated for US private websites — but legally valuable: No US statute requires a specific accessibility statement for private commercial websites. However, in ADA Title III litigation, courts regularly weigh the presence of an accessibility statement as evidence of good-faith compliance effort. Its absence can strengthen a plaintiff’s argument that accessibility is not taken seriously. For any US business that wants to reduce ADA demand letter exposure, publishing an accurate statement is a low-cost, meaningful step.

7 elements every accessibility statement must include

Element 1 Required

Compliance status

State your current compliance level honestly using one of three standard terms:

Fully compliant — use only if a recent third-party audit confirms full WCAG 2.1 Level AA conformance. Almost no real-world site qualifies.
Partially compliant — the honest status for most sites. You meet most criteria but have documented known failures.
Not compliant — use if you have not yet audited the site or have significant known failures without a remediation plan.

“Partially compliant” with a list of specific known failures and target dates is more protective than “fully compliant” that a plaintiff can immediately disprove.

Element 2 Required

The standard and conformance level

Name the specific standard you are targeting: Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. This is the internationally recognized standard referenced in ADA settlements, CVAA rulemakings, and the EU Web Accessibility Directive. Do not write “we follow best practices” — this is vague and unverifiable. Name the standard.

If your site or app is covered by WCAG 2.2 criteria (newer interactivity, form design), you may reference 2.2 instead — but 2.1 Level AA is the current legal baseline in most jurisdictions.

Element 3 Required

Known failures and non-compliant content

List every known accessibility failure you have identified. For each, include:

What the failure is (e.g., “some older PDF documents lack text reading order and alternative text”)
The WCAG criterion it violates (e.g., WCAG 1.1.1 Non-text Content, Level A)
A target resolution date, or an explanation if it is out of your control (e.g., third-party embedded content)

Listing known failures honestly is more protective than omitting them. If a user or plaintiff encounters a failure you already knew about but did not disclose, it suggests you were concealing it. If you disclosed it and named a remediation date, you are demonstrating an ongoing process.

Element 4 Required

Feedback and contact mechanism

Give users a specific way to report accessibility problems. A dedicated email address is sufficient. A contact form also works, but the form itself must be accessible (labeled inputs, keyboard operable, no CAPTCHA that blocks screen readers).

Write a specific commitment: “We aim to respond within 48 hours.” A response commitment that you actually honour is meaningful. A generic “contact us” link to a general inquiry page is not.

Important: Because the contact@copperbaytech.com inbox delivery has not yet been confirmed, do not wire a new live mailto: contact for accessibility feedback until you have verified that address receives email. Use your confirmed inbox, or a simple contact form, for the feedback mechanism.

Element 5 Required

Date of last review

Include a specific date: “This statement was last reviewed on [Month Year].” A statement with no date, or one that says “we regularly review our accessibility,” is functionally useless as evidence — there is no way to verify the claim. A specific date that is within the past 12 months signals ongoing attention; a date more than 12 months old signals neglect.

Element 6 Recommended

Assistive technology compatibility notes

If you have tested your site with specific assistive technologies — VoiceOver on macOS, NVDA on Windows, TalkBack on Android — note which combinations work as expected and which have limitations. This is not required by WCAG itself but is part of the EU Web Accessibility Directive model statement and is useful for screen reader users deciding whether your site will work for them before they invest time in it.

Element 7 EU public sector: Required

Formal enforcement or complaints procedure

EU public-sector bodies must include a link to the relevant national enforcement body or ombudsman, where users can escalate complaints if they are not satisfied with your response. For EU public sector sites, this is mandatory under the Web Accessibility Directive. For private-sector sites, it is not required — but noting the relevant national body (e.g., the UK’s Equality and Human Rights Commission, or the relevant DPA) is a sign of transparency.

Fill-in template

Copy this template, fill in the highlighted fields, and publish it at /accessibility or /accessibility-statement. Update it every time you complete a remediation pass or make major site changes.

Accessibility Statement

Compliance status

[Your site name] is committed to ensuring digital accessibility for people with disabilities. We continually improve the user experience for everyone and apply the relevant accessibility standards.

This website aims to conform to Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. We are [fully compliant / partially compliant / not yet compliant] with these guidelines.

Known limitations

Include this section only if you have known failures. If none are known, omit it or state "We are not aware of any current accessibility barriers."

[Describe the failure, e.g., "Some older PDF documents lack structured reading order."] This affects WCAG [criterion number and name, e.g., 1.1.1 Non-text Content, Level A]. We are working to address this by [target date or quarter].

Assistive technology compatibility

We have tested this site with the following assistive technologies:

VoiceOver with Safari on macOS
NVDA with Chrome on Windows
[Add or remove as appropriate]

Feedback and contact

We welcome feedback on the accessibility of [your site name]. If you encounter an accessibility barrier, or if you need content in an alternative format, please contact us:

Email: [your confirmed accessibility email address]
We aim to respond within [48 hours / 3 business days].

Date of last review

This accessibility statement was last reviewed on [Month Year].

Tip — keep it specific: The most defensible statements name the exact WCAG criteria for each known failure and include real target dates. Courts and procurement reviewers notice the difference between a statement that names “WCAG 1.4.3 Contrast (Minimum), Level AA — target fix: Q4 2026” and one that vaguely says “we are working on improving contrast.”

Where to publish your accessibility statement

URL

Use a clean, predictable path: /accessibility or /accessibility-statement. Plaintiff attorneys and procurement reviewers look for it at these paths first. A statement buried at /legal/docs/access-policy-v3.html is as bad as no statement for discoverability purposes.

Footer link

Add a direct link in your site footer on every page. The footer is where users and automated scanners look for policy links. It should appear as “Accessibility” or “Accessibility statement” — not as a sub-item in a “Legal” dropdown.

Navigation

For sites where accessibility is important to the user audience (anything with a significant disabled user base, or EU public-sector sites), add a header nav link as well. For typical SaaS or content sites, a footer link is sufficient.

How often to update your accessibility statement

Update the statement’s “last reviewed” date and content:

After each remediation pass — remove resolved failures from the “known limitations” list, or update their status.
After any major site change — a new checkout flow, a new CMS, a new navigation structure, a new file upload component. New functionality introduces new potential failures; the statement should reflect whether you have tested the new additions.
At minimum, once per year — even if nothing changed, run a fresh ShipSafe scan, update the last-reviewed date, and confirm the known limitations list is still accurate.

A statement with a last-reviewed date more than 12 months ago signals that accessibility is not an ongoing practice. A statement updated regularly, even if it still lists known failures, signals that it is.

Common mistakes

Claiming “fully compliant” without an audit — this is the most common and most damaging mistake. A plaintiff can check your site with Axe in 30 seconds. If the first page has missing alt text, your “fully compliant” claim is a credibility liability, not a shield.
No “last reviewed” date — a statement with no date cannot demonstrate ongoing effort. Add a specific month and year, and update it on every review.
No feedback mechanism — a statement without a way to report issues is a compliance document that actively ignores users. The feedback channel is the point of contact for good-faith remediation.
Not linking it from the footer — a statement that exists but is not findable from every page is not serving its purpose. Footer link is the minimum; test that it works on mobile too.
Vague known-failures list — “some parts of our site may not be fully accessible” is legally meaningless. Name the specific failure, the WCAG criterion, and the target date.
Never updating it — a statement from three years ago that still lists the same “known failures” with no resolution dates suggests those failures are permanent, not in progress.

Check your site before publishing your statement

Before you write your compliance status and your known-failures list, run a current scan so your statement reflects the actual state of the site. ShipSafe surfaces the four failures most commonly cited in ADA demand letters — missing language attribute, unlabeled inputs, missing alt text, color contrast — in a single scan. Your statement should be informed by a scan you ran this month, not by memory.

Scan my site with ShipSafe first →

Related ShipSafe guides:

Frequently asked questions

Is an accessibility statement legally required?

It depends on where you operate. EU public-sector bodies must publish one under the Web Accessibility Directive. Private companies in the EU are not yet explicitly required to publish one, though the European Accessibility Act (EAA) implies documented compliance for many private-sector digital products. In the US, no statute requires an accessibility statement for private websites, but courts in ADA Title III cases treat its presence as evidence of good-faith effort — making it a meaningful risk-reduction step even where not mandatory.

What does “partially compliant” mean?

“Partially compliant” means your site meets most WCAG 2.1 Level AA criteria but has documented known failures you are working to address. This is the accurate status for almost every real-world site. The key is to name the specific failures rather than leaving the status vague — “some older PDFs lack reading-order tags; we are replacing them by Q4 2026” is far more credible than just saying “partially compliant.” Reserve “fully compliant” for sites with a recent third-party audit confirming it.

Should I list known failures in my statement?

Yes. Disclosing known failures is more protective than omitting them. Courts and regulators view honest disclosure combined with a remediation timeline as evidence of good faith. Omitting known failures while claiming “partially compliant” status creates a credibility problem if a demand letter or complaint later cites those exact failures. Name the failure, name the WCAG criterion, and include a target resolution date.

Where should I publish my accessibility statement?

Publish it on a dedicated URL — /accessibility or /accessibility-statement — and link to it from the footer of every page. The footer link is critical: it signals to users and plaintiff attorneys that the statement exists and is findable. A statement that requires searching to find has significantly lower legal weight than one directly linked in the footer nav.

How often should I update my accessibility statement?

Update it after each remediation pass, after major site changes that introduce new content or functionality, and at minimum once per year. The “last reviewed” date is the most-scrutinised field in enforcement reviews — a statement more than 12 months old suggests the commitment is performative rather than ongoing. Update the date even on annual reviews where nothing else changed, to confirm you checked and confirmed the information is still accurate.

Do I need a lawyer to write an accessibility statement?

No. An accessibility statement is a technical disclosure document, not a legal instrument. Write it yourself using accurate information about your compliance status and known failures. A lawyer’s input is valuable if you receive a demand letter or formal complaint, at which point the statement becomes evidence — but accurate honesty in your initial statement is more defensible than polished legal language overstating your compliance.

What should I do when someone contacts me through my accessibility statement?

Respond within the timeframe you committed to in the statement (48–72 hours is best practice). Acknowledge the reported issue, log it, reproduce it if possible, and either fix it or add it to your documented known-failures list with a target date. Close the loop by replying to the person who reported the issue with what you found and when it will be addressed. An ignored accessibility contact form is almost as damaging as not having one — responsiveness is part of what good faith means in practice.

Also in the Copper Bay Labs suite

Accessibility is one layer of pre-launch compliance. These free tools cover the rest:

Generate a privacy policy, terms of service, and cookie notice for your site — free, in your browser, no account.

Security headers HardenCheck

Scan your live site’s HTTP headers for missing CSP, HSTS, and other security hardening flags.

Secret scanning LeakCheck

Paste code or a config file and see exposed API keys and secrets flagged before they reach the repo.

Post-deploy ExposureCheck

Scan your live URL for exposed .env files, .git directories, source maps, and bundled secrets.