An accessibility statement page is a dedicated page where a website explains its commitment to accessibility, states which standard it follows, and tells visitors how to report barriers. The single most important element is an accessible, actively monitored contact channel paired with an honest conformance status, not an inflated claim of full compliance. The page should reference WCAG as the technical standard and display a visible last-updated date.
TL;DR:
- Clearly specify the accessibility standard targeted, such as WCAG 2.2, and honestly state the conformance level achieved.
- List known limitations per page or feature with plain-language examples to demonstrate honesty and build trust.
- Ensure the contact channel for reporting barriers is accessible, actively monitored, and provides a response timeframe.
- Regularly review and update the statement, especially after major site changes or on a set schedule, to reflect current accessibility status.
- Place the accessibility link prominently in the footer of every page and ensure the page is user-friendly for all visitors.
Table of Contents
- What to include on an accessibility statement page
- Example excerpts and a copyable template
- Where to publish the statement so people can find it
- Writing the statement clearly and making the page itself accessible
- U.S. legal context and litigation risk
- Communicating accessibility policies to different user groups
- Keeping the statement current after the first review date
- Forge Web Studio's approach to accessibility statements
- How we can help you publish and maintain yours
- FAQ
- Sources
What to include on an accessibility statement page
A usable statement covers eight things, and skipping any of them weakens the user experience and your legal footing.
- Commitment statement: who the policy covers (all visitors, specific user groups, mobile and desktop) and why accessibility matters to the organization.
- Standard targeted: name the version, such as WCAG 2.2 or WCAG 2.1, and state the conformance level honestly rather than claiming full compliance.
- Known limitations: plain-language examples, such as "some PDF forms from before 2024 are not yet screen-reader friendly."
- Measures taken: automated scans, manual audits, testing with assistive technology users, and staff training.
- Tested environments: the browsers and screen readers checked, so visitors know what has actually been verified.
- Contact and reporting options: email, phone, or an accessible form, plus a stated response timeframe.
- Review date and cadence: when the page was last reviewed and how often it will be revisited.
- Third-party content disclaimer: an honest note that embedded widgets or vendor tools may not fully meet the same standard, alongside a formal complaint route.
A commitment statement, a named standard, known limitations, measures taken, and a reporting contact make up the core structure the W3C Web Accessibility Initiative recommends, and that combination covers most of what a reasonable visitor or regulator expects to find.
Pro Tip: List known limitations by page or feature rather than as a vague blanket statement; specificity reads as honesty, not weakness.
Example excerpts and a copyable template
Seeing real phrasing makes drafting faster than starting from a blank page.
- A public-sector style excerpt: "This agency is committed to ensuring digital accessibility for people with disabilities. We are continually improving the user experience for everyone and applying the relevant accessibility standards."
- A private-sector style excerpt: "We want everyone who visits our site to have a good experience, regardless of ability or technology. We have worked with accessibility specialists to identify and fix barriers, and we welcome feedback."
- A product or tech-site excerpt addressing third-party widgets: "Our live chat widget and embedded video player are provided by outside vendors. We have asked these vendors to meet the same standard we target, but we cannot guarantee full conformance for their components."
A simple template to adapt:
- Heading: Accessibility Statement
- Short paragraph: commitment and scope
- Short paragraph: standard targeted and conformance status
- Short list: known limitations
- Short paragraph: measures taken
- Short paragraph: contact information and response timeframe
- Line: date of last review
Once drafted, test the statement page itself the same way you would test any other page, since a statement about accessibility that is itself hard to navigate undercuts its own message.
Where to publish the statement so people can find it
Placement determines whether the statement actually helps anyone.
- Link it from the sitewide footer on every page, using plain text like "Accessibility" or "Accessibility Statement."
- Mirror the link in a help menu or an about page when the site has one, so users scanning different navigation patterns still find it.
- Avoid burying the only link inside a PDF, an image, or a dropdown that itself requires a mouse to open.
- For larger organizations or public entities, treat the footer link as a fixed identifier component that appears identically across subsites.
- Never limit the link to the homepage; every page needs the same visible path to the statement.
Federal guidance from the Section508 recommends exactly this footer placement along with a visible last-reviewed date, and that practice translates well to private-sector sites even though it is not legally required there.
Writing the statement clearly and making the page itself accessible
Plain language beats technical jargon for the body of the statement. Swap WCAG success-criterion codes for descriptions a non-technical visitor would understand, and save the formal standard name for a single clear reference line.
- Use real headings (H1, H2) instead of bolded paragraph text that only looks like a heading.
- Write link text that describes the destination, never "click here."
- Build the reporting form with labeled fields and visible focus states.
- Check keyboard navigation, screen reader flow, and color contrast before publishing.
- State the response timeframe explicitly and name who monitors incoming reports, even if only by role rather than individual.
Pro Tip: Test your own statement page with a keyboard only. If you cannot reach the contact form without a mouse, visitors with motor impairments cannot either.
U.S. legal context and litigation risk
Federal agencies operate under direct requirements. The OMB memorandum M-24-08 and Section 508 guidance require agencies to maintain an accessibility statement and publish it in the sitewide footer with a visible review date.
Private businesses face a different picture. There is no specific statutory requirement to publish a statement, but its absence can be used as evidence of indifference once a complaint or lawsuit is filed. A recent DOJ Interim Final Rule extended compliance dates for state and local government sites and apps, and it references WCAG 2.1 AA as the technical standard for many public entities, a signal that private businesses often adopt voluntarily to reduce risk.
DOJ guidance on the ADA stresses that automated tools are useful but cannot substitute for manual and user testing; treat accessibility as an ongoing process, not a one-time scan.
- Publish an honest conformance status rather than an unqualified claim of full compliance.
- Keep the reporting channel monitored and respond within the window you publish.
- Document a remediation plan for known issues instead of leaving them unaddressed indefinitely.
A detailed primer on ADA website obligations walks through what small organizations typically need to consider.
Communicating accessibility policies to different user groups
A single statement has to work for screen reader users, people with motor impairments, people with cognitive or learning disabilities, and people on slow connections or older devices, which means the writing style matters as much as the content.
Avoid assuming technical fluency. A visitor using a screen reader does not need you to explain what a screen reader is, but a sighted visitor without a disability might benefit from a short note about why the page exists at all. Write the core commitment in short sentences near the top, then let detail follow for readers who want it.
Offer more than one way to reach you. Some visitors prefer email, others prefer a phone call, and some will only use an accessible web form. Listing all three, where feasible, respects different comfort levels and device constraints.
Avoid grouping disabilities into a single vague category like "users with disabilities" when specificity helps. Naming visual, auditory, motor, and cognitive considerations separately, even briefly, shows the statement was written with real barriers in mind rather than copied from a generic source. A practical accessibility checklist can help confirm the underlying fixes match what the statement promises, since a policy that overstates what has actually been built erodes trust fast once a visitor hits a real barrier.
Keeping the statement current after the first review date
A last-reviewed date only means something if the review actually happens on a schedule. Set a cadence, commonly every six to twelve months or immediately after a major redesign, and stick to it rather than letting the date go stale while the site changes underneath it.
Treat any significant site change as a trigger for an off-cycle review: a new checkout flow, a redesigned navigation menu, or a new third-party widget all shift what "known limitations" should say. The W3C Web Accessibility Initiative frames accessibility statements as living documents, not static disclaimers, and that framing matters more once a site has grown past its original launch state.
Assign the review to a specific role rather than leaving it to whoever remembers. A person or a small team should own the audit, update the limitations list, and republish the date. Keeping a regular maintenance plan alongside the accessibility review tends to keep both on schedule, since the two activities often surface the same technical debt.
Finally, log what changed between reviews in a short internal note, even if it never appears publicly. When a complaint arrives, being able to show a documented history of reviews and fixes matters far more than a single untouched statement from years earlier.
Forge Web Studio's approach to accessibility statements
We treat an accessibility statement as the output of a process, not a copy-paste task. Our general sequence runs audit, draft, manual and user testing, publish, then maintain, which matches the testing approach DOJ guidance points toward rather than relying on an automated scan alone.
Because we build sites quickly, we include accessibility checks as part of the overall build timeline instead of treating it as a separate project later. Working directly with the founder on each build means mobile clarity and accessibility get the same attention as lead flow and local search setup.
The most common mistakes we fix are a statement page that itself fails basic keyboard navigation, and a contact channel that lists an inbox nobody actually monitors. Both are quick to correct once flagged, and both matter more to a visiting regulator or frustrated user than the wording of the statement itself.
— Dylan
How we can help you publish and maintain yours
Drafting an accessibility statement, planning remediation, and building an accessible site from the ground up are part of what we cover across our Starter, Growth, and Custom Business Website builds.
- Rapid turnaround: most builds launch in three days to a week, so an accessibility review does not stall your project.
- Founder-led work: you work directly with the person building your site, not a rotating account team.
- Local search and accessibility expertise built into the same build, not sold as a separate add-on.
If you want a second opinion on your current site, request a free website review or check our pricing page to see what a Starter, Growth, or Custom Business Website build includes.
FAQ
How do I write an accessibility statement?
Start with a short commitment paragraph, name the standard you target such as WCAG 2.2, list known limitations in plain language, describe the measures you have taken, and include a monitored contact channel with a stated response timeframe. Close with the date you last reviewed the page.
What is an accessibility statement?
An accessibility statement is a dedicated page that explains a website's commitment to accessibility, the technical standard it follows, its known limitations, and how visitors can report barriers. The W3C Web Accessibility Initiative outlines these as the core components any statement should include.
Do I need to have an accessibility statement on my website?
Federal agencies are required to publish one under OMB and Section 508 guidance, while private businesses face no specific statutory mandate to do so. Its absence can still be used as evidence of indifference if an accessibility complaint or lawsuit arises, so publishing one is a practical safeguard even without a direct legal requirement.
Can you provide an example of a website accessibility statement?
A simple version reads: "We are committed to ensuring digital accessibility for all visitors. We target WCAG 2.2 AA, have identified some known limitations in older PDF documents, and welcome feedback through our monitored contact form, with a response within two business days." Adapt the specifics to match your own site's actual testing and limitations.
What should I do if my site cannot fully meet the standard yet?
State the gap honestly in the known limitations section rather than claiming full conformance, and note the remediation steps planned along with a rough timeline. Combining an honest status with a documented plan tends to reduce both user frustration and legal exposure compared to an overstated claim.
Sources
- Developing an Accessibility Statement — W3C Web Accessibility Initiative (WAI)
- Section508
- Extension of Compliance Dates for Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities