Insights · Accessibility Statement

Website accessibility statement template.

What a real accessibility statement must include, why each section matters, and a working template you can copy onto your /accessibility page today.

What is a website accessibility statement?

A public statement on your website that names the accessibility standard you target (almost always WCAG 2.2 AA), the conformance status you have actually reached, the known limitations, and a contact path for users who run into accessibility issues. It's the operational counterpart to your audit report — your audit is internal evidence; your statement is the public-facing posture.

The statement does three jobs at once. It tells users with disabilities what to expect and how to reach you when something is broken. It documents your good-faith effort, which becomes part of the evidence record if a complaint or demand letter ever comes in. And it operationally forces your team to keep the underlying conformance posture honest — because nothing exposes a stale accessibility program faster than a stale accessibility statement.

The five sections every statement must include

Optional sections are common, but the following five are not optional. If any of these is missing, the statement isn’t doing the job it’s there to do.

  1. Conformance target. Name the standard you’re targeting — almost always WCAG 2.2 AA. State the W3C reference URL.
  2. Conformance status. Honest assessment: fully conformant, partially conformant, or non-conformant. Almost always “partially conformant.”
  3. Known limitations. Specific things that don’t conform yet, with reason and target remediation date if you have one. Empty list is acceptable if you genuinely have none.
  4. Feedback and contact path. An email address (and ideally a phone number) where users can report accessibility problems. Commit to a response time — three business days is standard.
  5. Date statement was last reviewed. A stale date signals a stale program.

The template

Copy the block below to your /accessibility page. Replace the bracketed placeholders. The italic notes in [square brackets] are guidance — delete them before publishing.

Accessibility statement

[Your organization name] is committed to ensuring digital accessibility for people with disabilities. We are continuously improving the user experience for everyone and applying the relevant accessibility standards to our website, [yourdomain.com].

Conformance status

The Web Content Accessibility Guidelines (WCAG) define requirements for designers and developers to improve accessibility for people with disabilities. WCAG defines three levels of conformance: Level A, Level AA, and Level AAA.

[yourdomain.com] is partially conformant with WCAG 2.2 level AA. “Partially conformant” means that some parts of the content do not fully conform to the accessibility standard.

Feedback

We welcome your feedback on the accessibility of [yourdomain.com]. Please let us know if you encounter accessibility barriers:

  • Email: [accessibility@yourdomain.com]
  • Phone: [your phone number]
  • Postal address: [your address]

We try to respond to feedback within three business days.

Compatibility with browsers and assistive technology

[yourdomain.com] is designed to be compatible with the following assistive technologies:

  • NVDA with Firefox or Chrome on Windows
  • VoiceOver with Safari on macOS and iOS
  • TalkBack with Chrome on Android
  • Voice Control on macOS and iOS
  • Dragon NaturallySpeaking on Windows

[yourdomain.com] may not be fully compatible with versions of Internet Explorer prior to IE11 or with browsers that have JavaScript disabled.

Technical specifications

Accessibility of [yourdomain.com] relies on the following technologies to work with the particular combination of web browser and any assistive technologies or plugins installed on your computer:

  • HTML
  • WAI-ARIA
  • CSS
  • JavaScript

Limitations and alternatives

Despite our best efforts to ensure accessibility of [yourdomain.com], there may be some limitations. Below is a description of known limitations, and potential solutions. Please contact us if you observe an issue not listed below.

Known limitations for [yourdomain.com]:

  1. [Example: User-generated content. Comments and reviews submitted by users may not always meet accessibility standards. We cannot ensure the quality of third-party content. If you find an inaccessible user-generated comment, please report it.]
  2. [Example: Older PDF documents. PDFs uploaded before [date] may not be fully accessible. We are in the process of remediating these documents and replacing them with HTML alternatives where possible. Please contact us if you need an accessible version of any document.]
  3. [Example: Embedded third-party video. Captions on videos hosted by third-party platforms (YouTube, Vimeo) depend on the platform’s captioning. If you find a video without captions, please contact us.]

Assessment approach

[Your organization name] assessed the accessibility of [yourdomain.com] by the following approaches:

  • External evaluation by [URCO / your audit vendor]
  • Self-evaluation against WCAG 2.2 AA success criteria
  • Automated testing with axe-core, WAVE, and Lighthouse
  • Manual screen-reader testing with NVDA, VoiceOver, and TalkBack

Formal complaints

We aim to respond to feedback within three business days. If you are not satisfied with our response, you may file a formal complaint:

  • For US-based concerns about ADA Title III: U.S. Department of Justice, Civil Rights Division — ADA.gov
  • For organizations receiving federal funds (Section 504): the relevant federal agency administering the funding (e.g., the U.S. Department of Education for educational institutions).

Date

This statement was last reviewed on [Month Day, Year].

Optional sections to consider

  • Audit summary. A one-paragraph reference to the most recent audit (date, vendor if external, conformance percentage by WCAG criterion).
  • Continuous improvement statement. Your monitoring cadence and the cadence at which you re-audit. Quarterly is the URCO default.
  • Third-party content disclaimer. If your site embeds third-party services (chat widgets, payment iframes, video players, comment systems), the limits of your accessibility responsibility for those.
  • Procurement statement. For schools, governments, and large organizations: the accessibility requirements you set for vendors when you procure new technology.
  • Conformance report link. A link to the per-success-criterion conformance table from your most recent audit. URCO recommends posting a redacted version publicly.

Anti-patterns to avoid

  • “This site is fully ADA compliant.” There is no government certification of ADA compliance for websites. The phrase invites scrutiny that “partially conformant with WCAG 2.2 AA” does not.
  • An “accessibility statement” that is actually a sales pitch for an accessibility overlay. Overlays are not a defense; statements that read like overlay marketing are a red flag.
  • No date. A statement without a last-reviewed date is functionally invisible.
  • No contact path. Statements without a real way for users to report issues fail their primary purpose.
  • Linking the statement only from a privacy or terms page. The statement should live at /accessibility and link from the global footer.

Related

● Related ADA reading

More from the URCO ADA cluster.

FAQ

Accessibility statement — FAQ.

Is a website accessibility statement legally required?

For ADA Title III private-sector sites, no — the statement itself is not legally required. But every accessibility-defense framework an attorney would recommend includes one, because the statement is part of the documentation a court would expect to see when evaluating whether a business has made good-faith efforts. For Section 504-covered organizations and for ADA Title II state and local government sites, the DOJ's 2024 final rule explicitly references the practice. URCO ships a statement on every site, regardless.

What's the minimum every accessibility statement must include?

Five things: (1) the conformance target you are aiming for (e.g., WCAG 2.2 AA), (2) the conformance status you have actually achieved (fully conformant, partially conformant with named exceptions, or non-conformant with named limitations), (3) a public contact path for accessibility issues — email, phone, or both, (4) a remediation commitment with a target response time, and (5) the date the statement was last reviewed. The template below covers all five plus the optional sections most well-built statements include.

Should we say "fully compliant" or "partially compliant" in the statement?

"Partially conformant" is almost always the right answer, even on well-built sites. WCAG conformance is per-success-criterion against rendered output — and any real-world site with user-generated content, third-party widgets, or PDFs will have edge cases. Saying "fully compliant" exposes you when an investigator finds even one criterion that fails. "Partially conformant" with named exceptions is the honest, defensible posture.

How often should we update the accessibility statement?

Review the statement quarterly and after any major site release. The "last reviewed" date matters — a stale statement is a signal that the underlying compliance posture is also stale. Set a calendar reminder. The review usually takes 30 minutes if your audit and remediation pipeline is healthy.

Where should the accessibility statement live?

On a dedicated page at /accessibility, linked from the global footer. Don't bury it in a privacy policy or a terms-of-service page. The dedicated URL is what's referenced by accessibility regulators and investigators, and it's what a screen-reader user would expect to find when they look for it.

(08) — Ready when you are

Fix the friction.

Build a website that is accessible, search-ready, conversion-aware, and built to perform.

Free AuditStart a Project