# DRAFT — accessibility statement for [website or product]

Do not publish this file with unresolved placeholders. This is an original drafting aid from What Is ADA / Grow Wild, updated October 19, 2026. It is not a completed evaluation or a universal legal template.

## Commitment and scope

[Organization] aims to make [website or product and URLs] accessible to people with disabilities. [Explain the commitment in language the owner has approved.]

## Report a barrier or request help

Contact [confirmed receiving team and email address] or [form URL and relevant option]. If the form is difficult to use, [provide a usable alternative].

Tell us the page address, what you were trying to do and where you got stuck. Browser, device and assistive-technology details can help if you are comfortable sharing them. Tell us which information or task you need help accessing; you do not need to disclose a diagnosis.

[Add a response commitment only if the responsible team has approved it and can support it. Do not invent a telephone number, opening hours or repair deadline.]

## Target and evaluation status

Our accessibility target is [standard, version and level].

[Describe the conclusion supported by a documented evaluation, including its scope, date and link. If no whole-site conclusion is established, say that explicitly. Do not select “fully conformant” or “partially conformant” simply because a template offers it. A target is not a test result.]

## What has been checked

For each completed check, summarize:

- The page or task and the version tested.
- The actual test date and environment.
- The method and what was observed.
- A link to a public evidence summary, where appropriate.
- What the result does not establish.

[Use plain language here. Detailed commands, versions and transcripts can live in the linked record. Do not imply that a single test establishes routine testing or participant usability.]

## Known limitations and alternatives

[Describe each verified barrier or product limitation in useful terms: the affected task, what happens and an available workaround. Give a repair status or date only when it is supported by the issue record and owner.]

[Separately describe important untested scope. Missing evidence is not proof of either failure or accessibility. Do not copy speculative issues from another website.]

## Technical requirements

[State requirements relevant to visitors, such as JavaScript for interactive tools. List tested browser/assistive-technology combinations as tested combinations, not universal compatibility promises.]

## Ownership and review

Maintained by: [responsible team]
Last reviewed: [actual date the statement wording was reviewed]
Review triggers: [product, issue or test changes that require checking the statement]

[The statement review date is not the date of a full audit unless that audit actually occurred. Preserve original test dates and versions.]

---

## Internal publication checklist — remove from the public statement

- [ ] Every factual claim has a dated source, scope and owner.
- [ ] Organizational and applicable jurisdiction-specific requirements have been checked.
- [ ] Targets, evaluation conclusions, completed checks and future plans are distinct.
- [ ] Known issues and untested coverage are described separately.
- [ ] Feedback links, email address, form options and alternative route are checked.
- [ ] An authorized delivery check has reached the intended receiving team; receipt is retained. If pending, keep it pending and do not claim delivery verified.
- [ ] Any response-time commitment is approved and supportable.
- [ ] Desktop/mobile rendering, headings, keyboard navigation and links are checked; other needed accessibility checks are recorded with their actual results.
- [ ] No draft placeholders, invented audit dates or copied compatibility claims remain.
- [ ] The responsible owner has reviewed the final wording and publication date.
- [ ] A discoverable site link and a process for future review are in place.

Keep the internal evidence review separately from the visitor-facing statement. This checklist does not establish conformance.

Worked example: https://whatisada.com/workflows/write-accessibility-statement#worked-example
Primary guidance: https://www.w3.org/WAI/planning/statements/