Reviewed October 21, 2026

What an accessibility statement page should actually include

An accessibility statement is a public commitment plus a practical help page. The elements auditors and users look for, the vague language to avoid, and how to keep the page true over time.

What the page is for

An accessibility statement tells visitors what standard you aim for, what you know still falls short, and how to reach you when a barrier blocks them. It serves three audiences at once. Users who need a contact route today, evaluators checking your conformance claims, and your own team, who inherit a public document they are expected to keep true.

A statement is not a badge and it is not legal armor. Courts and auditors treat inflated claims with missing substance as worse than modest claims with evidence. The page earns its keep by being specific, current, and connected to a feedback channel that a real person answers.

The elements that belong on it

Name the standard and level you target, most commonly the Web Content Accessibility Guidelines at AA level, and the date the statement was last reviewed. List the scope honestly, which parts of the site or product the statement covers and any third party areas, like a booking engine or embedded content, that follow a different path.

Include the known limitations section even though it feels uncomfortable. Naming the PDF archive that is not yet remediated, with the alternative format offered on request, demonstrates the monitoring the statement claims. Then give the feedback route prominent placement, email at minimum, with a response time commitment you actually meet.

Language that undermines the page

Vague effort language is the tell of a statement nobody maintains. We are committed to ensuring digital accessibility for everyone, with no standard, no date, and no contact, communicates nothing and convinces no one who reads statements professionally. Superlatives like fully accessible and one hundred percent compliant are claims almost no real site can defend.

Avoid blaming the tools. Statements that attribute every barrier to third party vendors read as abdication, especially when the vendor content is core to the transaction. Own the experience you present to users, describe the workaround or timeline, and reserve vendor detail for procurement conversations where it can change something.

Keeping the statement true

Assign an owner and a review cadence. Accessibility statements rot quietly as sites change, so tie reviews to releases or a quarterly checklist, whichever comes first. When an audit happens, when a known limitation gets fixed, or when contact details change, the statement updates in the same week, not the same year.

Track the feedback the page generates as its own metric. Contacts through the statement are the cheapest accessibility testing you will ever receive, they identify real barriers encountered by real users on real tasks. A statement that produces fixes visibly over time is the strongest evidence that the commitment behind it is operational rather than decorative.

Related reading

If this topic is useful, these earlier guides go deeper on connected questions: How website accessibility claims get tested: what auditors and plaintiffs look for, Training your support team for accessibility requests: a practical program, and WCAG 2.2 for Shopify stores: what changed and what to check.

Frequently asked questions

Is an accessibility statement legally required?

In some sectors and jurisdictions, effectively yes, and public sector rules often specify one explicitly. For most private businesses it is not a standalone legal requirement, but it is standard evidence of a conformance process and is expected by enterprise buyers, auditors, and regulators reviewing complaints.

What standard should an accessibility statement cite?

Most statements cite the Web Content Accessibility Guidelines, WCAG, at version 2.1 or 2.2 and level AA, because that is the benchmark laws and procurement rules most commonly reference. Cite the version you actually evaluate against, not the newest one by default.

Should I list accessibility problems on the statement?

Yes, the significant known ones, with alternatives or timelines where you have them. Honest limitation sections are a mark of a maintained program. A statement claiming no issues at all usually signals that nobody is actually checking.

How often should the statement be updated?

At least annually, and immediately when audits complete, major limitations are fixed, or contact routes change. Date the statement visibly. A recent review date on an otherwise modest statement builds more confidence than grand claims dated three years ago.