An accessibility statement is not a marketing page. It is a legal artifact that explicitly documents what standard your site aims for, what is currently conformant, what is not, how users can report problems, and how you respond. Website accessibility statement services that treat it otherwise — copy-paste boilerplate, vague promises, undated claims of "full compliance" — have.
An accessibility statement is not a marketing page. It is a legal artifact that explicitly documents what standard your site aims for, what is currently conformant, what is not, how users can report problems, and how you respond. Website accessibility statement services that treat it otherwise — copy-paste boilerplate, vague promises, undated claims of "full compliance" — have accidentally been handing plaintiffs' firms evidence for years. The difference between a statement that strengthens your legal position and one that weakens it comes down to surprisingly specific language choices.
Why the Statement Exists at All
The W3C Web Accessibility Initiative recommends every site publish an accessibility statement. Regulators in several jurisdictions require one. Public-sector organizations in the EU operate under mandatory language defined by the Web Accessibility Directive. US state and local government under the 2024 DOJ Title II rule are required to publish accessibility statements that describe conformance with WCAG 2.1 AA. Private-sector US businesses are not federally mandated to publish one, but the statement has become a de facto standard, and its absence is sometimes cited by plaintiffs as evidence of a lack of a program.
The strategic purpose is threefold: it tells users with disabilities what to expect and how to get help, it documents the organization's good-faith efforts (which can matter significantly in settlement posture), and it creates a formal channel for reported issues that, when staffed properly, heads off complaints before they become lawsuits. A well-run ADA compliance program treats this page as a living document tied to an actual operations cadence, not a static footer link.
The "Fully Compliant" Language Trap
The single most common mistake is claiming full WCAG conformance. Sites say things like "our website fully complies with WCAG 2.1 Level AA" because it sounds good in a statement. The problem is that full conformance is extremely difficult to maintain across a dynamic site and essentially impossible to verify at any single moment. Plaintiffs' firms now routinely use the claim against defendants: here is your own statement saying you are fully compliant, here is evidence your site is not, therefore you misrepresented.
The better language follows the W3C recommended pattern: state the standard you target, state whether the site is fully conformant, partially conformant, or non-conformant, and explicitly name known exceptions. "This website aims to conform with WCAG 2.2 Level AA. It is partially conformant, meaning that parts of the content do not fully conform to the accessibility standard" is defensible. "We are proudly fully compliant" is a liability.
What a Real Statement Includes
The W3C template and most enforceable regional variants require a consistent core. A real statement covers nine things: the name and scope of the site the statement covers, the accessibility standard targeted, the conformance status, a list of known accessibility limitations, the date of the most recent review, the testing methodology used, feedback contact details, enforcement procedures for unresolved complaints, and information about alternative access arrangements.
The scope section matters more than most drafters realize. A single organization often operates a marketing site, a customer portal, a mobile app, and a vendor login — each potentially at different conformance levels. A blanket statement covering "our web presence" invites trouble. Scoped statements that name each property and its current status are honest and legally cleaner.
A strong accessibility statement does three specific things: states the targeted standard (WCAG 2.2 AA), names known exceptions honestly, and commits to a named response SLA for user feedback. Vague "we are committed" copy that claims full compliance actively weakens legal defense.
VPAT, ACR, and the Procurement Context
Three related documents often get confused. A Voluntary Product Accessibility Template (VPAT) is a standardized self-reporting format created by ITI, most recently in version 2.5. An Accessibility Conformance Report (ACR) is what you get when a VPAT is filled in and completed for a specific product. The public-facing accessibility statement is distinct from both — shorter, written for users, and focused on how to get help.
The VPAT/ACR matters most in B2B and government procurement. Most federal contracts require Section 508 conformance, and vendors submit ACRs as part of the bid package. Large enterprise buyers increasingly require the same. A SaaS company without an up-to-date ACR simply cannot sell to many government, university, or Fortune 500 accounts — compliance language in contracts is blocking, not optional. Organizations that need both documents usually draft the ACR first (it is more rigorous) and summarize from it into the consumer statement.
The Feedback Loop That Actually Works
The most load-bearing part of the statement is the feedback channel. A site that publishes "email accessibility@example.com" but has no one monitoring the address is worse than having no statement at all, because the plaintiffs' discovery will include the fact that the email went unanswered. A working feedback loop needs a monitored inbox, a committed response SLA (typically 48 or 72 business hours for acknowledgment), a defined path for escalation, and internal routing to whoever can actually fix identified issues.
This is where the statement crosses from documentation into operations. Most organizations set up the email, publish the statement, and never track responses. A properly run program logs every feedback message, categorizes them, feeds real issues into the remediation backlog, and reports quarterly on response times. Pair this with the testing cadence in a proper accessibility audit program and you have both the evidence of good faith effort and the mechanism for continuous improvement.
Alternative Access and Undue Burden
One of the more nuanced statement elements is alternative access arrangements. If a specific piece of content or functionality is inaccessible, the statement should describe how a user with a disability can access the same information through another channel — a phone line, an email address, a scheduled appointment. This matters especially for content like hearing-related accommodations covered in hearing-accessible web design, where captioning and transcripts take time to produce after new video content ships.
Alternative access is not an excuse to leave the site inaccessible. It is a stopgap while remediation happens. Regulators and courts generally view it favorably when offered honestly alongside an active remediation plan, and unfavorably when used as a permanent dodge. The statement should name alternative channels specifically, not "contact us" — a staffed phone line with known hours beats a form that vanishes into a generic queue.
Update Cadence and the Dated Review
A statement dated 2020 on a site that has been redesigned twice since then is functionally worthless. The statement should be reviewed at least annually and after any material change to the site — a redesign, a platform migration, a significant new feature. Each review should be dated and signed off by whoever owns the accessibility program internally.
The review date is often cited in litigation either way: a fresh date supports the claim of ongoing commitment, a stale one supports the opposite claim. Keep the review tied to the annual audit cycle, update the statement's "last reviewed" field each pass, and archive prior versions. A good website accessibility statement services engagement includes drafting the current statement, building the feedback workflow, and setting a calendar for the next review — because the statement is only as useful as the operational program behind it.
Need a Statement That Holds Up?
We draft legally-sound accessibility statements, wire up the feedback workflow, and tie the review cadence to your audit program so documentation stays honest and current.
Get My Free Audit →