A website accessibility statement needs exactly three things to be useful: a stated conformance target (usually WCAG 2.1 or 2.2 at Level AA), an honest list of known limitations where the site falls short of that target, and a working contact method for someone to report an accessibility barrier. Leave any one of those out and the statement reads as a formality rather than a real commitment, and it stops being much help if a complaint or a demand letter ever tests it.
It also needs to be honest about what it is. A statement is a disclosure document, not a fix. Publishing one does not make a site accessible, and treating it as a substitute for actual remediation work is the single most common mistake site owners make with this document.
What Does an Accessibility Statement Actually Need to Say?
Start with the conformance target: name the standard and the version, such as “this site aims to conform to WCAG 2.2 Level AA.” Vague language like “we care about accessibility for everyone” says nothing measurable and gives a reader no way to know what was tested against.
Next comes the limitations section, and this is the part most sites skip entirely. List the specific pages, components, or content types that do not yet meet the target: an embedded third-party video player without captions, a PDF report that has not been remediated, a legacy form that does not support keyboard navigation. Naming these specifics, rather than a blanket “some content may not be fully accessible,” is what makes the statement credible and shows the assessment was real.
- No named conformance target
- Generic, non-specific accessibility language
- No specific known limitations listed
- No dedicated contact channel
- Names WCAG 2.2 Level AA as the target
- Lists exact pages or components that fall short
- States a response-time expectation
- Reviewed on a set cadence
Finally, give a working feedback channel: an email address, a contact form, or a phone number specifically for accessibility issues, plus a rough response-time expectation. This is also where a generated accessibility statement in the Accessibility Statement Generator saves time over drafting from scratch, since it prompts for the conformance target, limitations, and contact details as required fields rather than optional afterthoughts.
What Does ADA Actually Require?
The Americans with Disabilities Act does not name a technical web standard by itself. Title III (covering private businesses open to the public) has been applied to websites through court rulings and Department of Justice guidance rather than a specific regulation, and courts have consistently pointed to WCAG as the practical benchmark when deciding whether a site provided equal access. Title II, which covers state and local government sites, changed this in 2024 when the DOJ finalized a rule requiring WCAG 2.1 Level AA conformance on a set compliance timeline based on the size of the government entity.
The practical upshot for a private business site: there is no ADA checklist to satisfy directly, but WCAG 2.1 AA is the standard plaintiffs’ attorneys, courts, and the DOJ itself treat as the reference point. Writing a statement that names WCAG AA as the target and is honest about gaps is the closest thing to an ADA-aligned baseline that currently exists.
How Does WCAG Fit Into This?
WCAG (Web Content Accessibility Guidelines) is published by the W3C and organized into three conformance levels: A (minimum), AA (the level almost every legal and regulatory reference means when it says “WCAG compliant”), and AAA (the strictest level, not expected of most general-purpose sites). WCAG 2.1 and 2.2 are the current versions in active use, with 2.2 adding criteria around things like focus visibility and target size on top of 2.1’s requirements.
When a statement names a WCAG conformance level, it should also say which version, since 2.1 and 2.2 differ in a handful of criteria. “WCAG 2.2 Level AA” is a more precise and more defensible claim than just “WCAG compliant,” and it makes the limitations section easier to write, because the site owner can check each success criterion in that specific version against what exists on the site.
WCAG Conformance Levels
| A | AA | AAA | |
|---|---|---|---|
| Minimum WCAG level | |||
| Level named in most legal and regulatory guidance | |||
| Expected of general-purpose sites | |||
| Strictest level, rarely expected |
What Does the EU’s EN 301 549 Add?
EN 301 549 is the European harmonized accessibility standard, and it is the technical standard referenced by the EU’s Web Accessibility Directive (for public sector bodies) and the newer European Accessibility Act (which extends coverage to many private sector digital products and services, including e-commerce, banking, and transport sites). It incorporates WCAG 2.1 AA as its core web content requirement, so a site that already conforms to WCAG 2.1 AA has done most of the work EN 301 549 asks for.
Where it goes further is outside pure web content: EN 301 549 also covers requirements for documents, software, hardware, and real-time communication features like live chat or video calls, areas WCAG alone does not fully address. A site with EU users or EU public sector obligations should treat EN 301 549 as the broader umbrella standard and WCAG 2.1 AA as the web-specific baseline sitting inside it, and say so explicitly in the statement rather than citing only one or the other.
Why Publishing a Statement Is Not a Substitute for Fixing the Site
None of the above changes the fact that an accessibility statement documents a state of compliance, it does not create one. A site with a well-written statement that lists five known limitations and no plan to address them is more exposed, not less, than a site with no statement at all, because the statement itself becomes evidence that the gaps were known and left unfixed.
Treat the statement as the disclosure layer on top of ongoing remediation work: an automated and manual accessibility audit, a prioritized fix list, and a review cadence (most organizations that take this seriously revisit the statement and the underlying site every six to twelve months, or after any major redesign). The statement should be updated every time a listed limitation gets fixed or a new one is found, not written once and left untouched for years while the site changes underneath it.
Getting the wording right, naming a real conformance target, disclosing real limitations, and giving a real contact method, is a small part of a much larger effort, but it is the part that shows up in writing when someone asks what the site committed to.