Audit operations

Accessibility Statement: Template and a Worked Example

Published by whatisADA / Grow Wild Agency · Updated

Purpose and preparation

Write a useful website accessibility statement with an editable template and a completed review of our own claims. Separate your WCAG target from evaluated conformance, describe dated tests and limitations, and give visitors a clear way to report a barrier.

A practical example

We corrected What Is ADA’s own statement after comparing its broad testing and compatibility claims with our retained keyboard, contrast and real-NVDA records. The worked example below shows which claims changed and why.

How to check it

  1. Identify the statement owner, website or product, target standard and any organizational or jurisdiction-specific requirements. Gather dated evaluation records with tested versions and scope.
  2. Check each conformance, compatibility and testing-process claim against that evidence. Distinguish a target, a completed task test, a recurring practice and an untested area.
  3. Describe verified limitations in plain language with a practical alternative where available. Do not turn missing test coverage into an invented failure or a clean bill of health.
  4. Provide a feedback route and an alternative if the form is difficult to use. Check the address, form choices and links; separately arrange an authorized delivery check. Publish response commitments only when the receiving team can support them.
  5. Review the rendered statement, links and downloads on desktop and mobile. Retain the claim-to-evidence review, publish the real review date and recheck affected wording when the product or evidence changes.

Worked example: correcting our own accessibility statement

Reviewed October 19, 2026 · Grow Wild’s maintenance work on What Is ADA

Our website’s accessibility statement listed broad test coverage and dates that the retained evidence did not support. We had useful keyboard, contrast and real-NVDA records, but they covered selected tools and tasks. The repair was to make the statement describe that evidence accurately and help visitors reach us.

Start with what a visitor needs

Put the feedback route near the top. Explain the affected site, your target, what you know about its accessibility and useful workarounds. Keep detailed test versions and transcripts one link away. A visitor reporting a blocked task should not have to read an audit report first.

W3C’s statement guidance recommends useful, plain-language information, a contact route and transparent limitations. Its generator is a starting point; each statement still needs to fit its organization and applicable requirements.

Five claims we checked against the records

  1. Target versus conformance status

    The previous statement called the site “partially conformant.” Our retained checks did not establish a site-wide conclusion. The revised statement keeps WCAG 2.2 AA as the target and says that whole-site conformance has not been established. A successful task test does not evaluate every applicable criterion, page and complete process.

  2. One screen-reader journey versus a compatibility list

    The earlier page listed NVDA, JAWS, VoiceOver and TalkBack compatibility. The evidence supports one recorded journey with NVDA 2026.2, Chromium 156.0.8078.4 and Windows Server 2022. The actual speech record distinguishes the automatic results-heading announcement from counts read with Down Arrow. We describe that observation and leave other combinations unverified. This statement page itself was not part of that NVDA session.

  3. A completed check versus a repeating process

    The previous wording promised checks on every pull request and every page, and periodic sessions with assistive-technology users. A stored test result does not prove a recurring programme. We removed those unsupported claims. Our Guidepup session operated real NVDA, but did not involve a disabled participant. We link the separate keyboard record without calling it screen-reader testing.

  4. A tested limitation versus a guessed issue list

    The heading validator’s documented input limit is concrete: one supported heading per line; nested markup and multiple headings on a line are unrecognized. Readers can use the provided samples. We link the actual repair and retest. We removed speculative claims about older images, tables and PDFs with unsupported completion dates. Untested coverage belongs in a separate explanation; it is not proof of a defect or proof that no defect exists.

  5. A usable feedback route versus an invented promise

    We removed an unverified phone number and unsupported response-time commitments. The statement now points to the contact form’s existing “Accessibility Issue” option and gives Grow Wild’s supplied email address as an alternative. Route and address checks do not establish inbox delivery or response speed. We did not send a test enquiry during this content review; an authorized delivery check and a measured response process remain separate operational evidence.

Example wording supported by our test

On October 19, 2026, we checked the heading validator’s error-and-correction task with NVDA 2026.2 and Chromium on Windows Server 2022. The recorded session read the input instructions, announced the results heading and exposed the error and corrected result through reading commands. This check does not establish whole-site conformance or compatibility with other screen readers.

This wording belongs to our recorded task. Replace every detail with your own results before using it elsewhere. The dates identify the completed test, not an invented site-wide audit.

Download a draft and the completed claim review

Editable accessibility statement template (Markdown)

Our completed statement claim review and evidence links (JSON)

The template is an unpublished draft with placeholders and review prompts. It contains no preselected conformance verdict, guaranteed response time or assumed testing programme. Resolve the placeholders and any required organizational or jurisdiction-specific wording before publication.

Keep the statement connected to change

Give the statement an owner. When a repair, new feature or new test changes a claim, compare the statement with the issue and test records. Preserve older results with their tested versions. A “last reviewed” date should mean someone reviewed the wording; it does not mean every linked test was repeated that day.

Before publishing, check the feedback links, form labels, mobile layout and any download. Arrange an authorized delivery check with the receiving team. If that check is pending, retain it as pending; do not describe an email link as a verified support service. Keep response-time language tied to an approved, supportable commitment.

Use the audit-scope guide to plan missing coverage. A statement helps visitors understand the current position; it does not replace evaluation, remediation or testing with people with disabilities.

What can be missed

A statement that says the site is fully compliant without supporting evidence can mislead visitors. Generic promises are less useful than specific scope and honest limitations.

Record your test

Use this worksheet to record what you actually checked. Notes stay on this device when you choose Save; they are not sent to us. Avoid personal or confidential information on shared devices.

These are your observations, not automated results or a conformance certificate. A complete evaluation needs appropriate scope, supported technologies, all applicable criteria and relevant page states.

Primary sources and scope

This is independent implementation guidance with original examples. The linked standard contains the full definitions, exceptions and conformance requirements. A criterion or checklist alone does not establish legal applicability or whole-site conformance.