How to Create and Operate an Accessibility Statement: A Practical Template That Turns Social Responsibility into Continuous Improvement
Executive Summary (Key points first)
- An accessibility statement is not a “we’re compliant” declaration. It’s a sincere promise in writing that clearly communicates current status, scope, limitations, improvement plans, and contact methods.
- If you’re aiming for WCAG 2.1 AA, your statement should, at minimum, include: scope / standards applied / conformance status / known issues / alternatives / contact / last updated date.
- The most important part is what happens after publishing. By running regular evaluations, fix prioritization, and inquiry handling, social responsibility becomes ongoing trust.
- This article includes copy-ready accessibility statement templates, examples for writing known issues, an inquiry response flow, and operational rules that are easy to get internal buy-in for.
Intended audience (specific): PR, Legal, General Affairs, HR; public agencies/municipal web teams; corporate site operators; product managers; accessibility leads; agency directors
Accessibility level: Targeting WCAG 2.1 AA (and assuming the statement itself is readable and meets keyboard access, contrast, and structure requirements)
1. Introduction: A Statement Is Social Infrastructure That Creates Peace of Mind
Accessibility work is both a technical/design challenge and a declaration of social responsibility. But in reality, it’s often hard to make everything perfect all at once. Site size, CMS limitations, legacy assets, videos and PDFs, external service integrations—there will always be remaining issues.
That’s why publishing an accessibility statement (policy/status) matters. This is not a document that says “there are no problems.” It’s a practical guidepath that honestly shares what’s working, what’s difficult, and how and when you will improve, and ensures that anyone who needs help can contact you without getting lost.
In this article, we’ll cover not only how to write a statement, but also the operational system needed so it doesn’t become “just for show,” turning it into something usable in real-world practice.
2. The 7 Essential Elements of an Accessibility Statement
An accessibility statement should be structured so readers can quickly judge: “Can I use this site?” Especially if you’re aiming for WCAG 2.1 AA, these seven items are the minimum you should include.
2.1 (1) Purpose (Why publish it?)
- Example: “We are continuously improving so that everyone can access information.”
2.2 (2) Scope (What is covered?)
- Domain, main directories, apps, sub-sites
- Clearly state exceptions (third-party services, embeds, legacy PDFs, etc.)
2.3 (3) Standards applied (What are you using as the benchmark?)
- Example: “We target WCAG 2.1 Level AA.”
2.4 (4) Conformance status (How far along are you?)
- Whether you say “conformant,” “partially conformant,” “non-conformant,” etc. can follow organizational policy, but add evidence such as evaluation method and evaluation date.
2.5 (5) Known issues (What is not working?)
- This is the most important part. Readers want to know: “Where might I struggle?”
- Write known issues not as excuses, but as impact + alternative.
2.6 (6) Alternatives (What should users do if they hit a barrier?)
- Examples: phone, email, form, chat
- Important: make it usable via text, and include reception hours / response expectations if possible.
2.7 (7) Last updated date and improvement plan (When will it be reviewed?)
- Last updated date, next review date, priority/roadmap (even a lightweight one)
- A statement that stops being updated tends to reduce trust—so make operations protect this.
3. Writing That Builds Trust: Designing for Sincerity
A statement is read not only by specialists, but also by affected users, their families, supporters, and help-desk staff. So it needs to be not only “correct,” but also “kind.”
3.1 Minimize jargon; if you use it, include a plain-language gloss
- “Screen reader” → “text-to-speech (read-aloud) software”
- “Contrast” → “the brightness difference between text and background”
- “Keyboard operation” → “using the site without a mouse”
3.2 Write less about why you can’t—and more about how you’ll help
- Bad: “We can’t support this due to system constraints.”
- Good: “Some PDFs may not support read-aloud. If you need the information, we can provide it in text—please contact us via the channel below.”
3.3 Use this format for known issues (it won’t collapse)
Location (e.g., Careers > Application form)
Problem (e.g., error messages are hard to understand with read-aloud)
Impact (e.g., difficult to correct input mistakes)
Alternative (e.g., accept applications via email)
Planned improvement (e.g., fix in next release; target by March 2026)
4. Copy-Ready Accessibility Statement Template
This “basic form” works for corporate sites, public-sector sites, and service sites. Add headings as needed.
4.1 Statement template (example)
## Accessibility Policy (Accessibility Statement)
### 1. Purpose
We are committed to continuous improvement so that everyone—regardless of age, disability, or environment—can access information and use our features.
### 2. Scope
- Covered: This website (key pages and key functions)
- Not covered (examples): pages provided by external vendors, third-party embedded content, some legacy materials (e.g., PDFs)
### 3. Target and Standards Applied
We aim to meet WCAG 2.1 Level AA.
### 4. Conformance Status
At this time, we are improving accessibility primarily across key pages and key functions.
Evaluation method: A combination of automated testing, manual testing (e.g., keyboard navigation), and checks using assistive technologies.
Evaluation date: YYYY-MM-DD
### 5. Known Issues (examples)
- Some PDF documents may be difficult to read aloud or reuse.
Alternative: If you need the content, we can provide it in text—please contact us via the channel below.
Planned improvement: From new publications onward, we will prioritize accessible formats and expand improvements over time.
- Some forms may have error guidance that is difficult to understand.
Alternative: We can accept requests via email or phone.
Planned improvement: We will address this in the next form update (target: YYYY-MM).
### 6. Contact (Accessibility Support)
If you experience difficulties using this site or have feedback, please contact us.
- Contact methods: Email / Phone / Contact form (choose applicable)
- Hours: Weekdays 9:00–17:00 (example)
- If possible, please include:
- The page URL or page name
- Your environment (device, OS, browser, read-aloud software, etc.)
- What you were trying to do and what happened
### 7. Updates
Last updated: YYYY-MM-DD
The key point of this template is: listing “out of scope” items should not become a shield. Even if something is out of scope, providing an alternative is what makes the statement kind and practical.
5. Known-Issues Examples by Common Situation
The hardest part is often deciding “how much to disclose.” A good approach is to list a small number of representative issues in order of impact—too many can exhaust readers.
5.1 Organizations with many PDFs
- Issue: Some PDFs lack tagging, making read-aloud and heading navigation difficult.
- Impact: Read-aloud users may struggle to grasp content; reuse (copying, etc.) may be difficult.
- Alternative: Provide the same content as HTML or plain text.
- Improvement: Prioritize accessible formats for new materials; remediate legacy PDFs starting with most-used.
5.2 Organizations with many videos
- Issue: Some videos may not have sufficient captions (including sound cues and speaker identification).
- Impact: Audio information may be hard to access.
- Alternative: Provide a text version (highlights or full transcript).
- Improvement: Standardize for new production and remediate existing videos by priority.
5.3 Form-centric services
- Issue: Some forms may not move focus to the error summary properly.
- Impact: Keyboard users may struggle to find what to fix.
- Alternative: Offer input assistance via support channels.
- Improvement: Standardize on a two-layer approach: error summary + inline errors.
5.4 Sites with third-party embeds
- Issue: Some third-party reservation widgets may not fully support keyboard navigation.
- Impact: Users may be unable to complete reservations.
- Alternative: Accept reservations via phone or email.
- Improvement: Keep alternative paths permanently available and share improvement requests with the vendor (report progress via statement updates).
6. Turning the Statement into Continuous Improvement: Publishing Is the Start
Publishing is not the goal—it’s the starting line. If operations stop, it looks like “we just wrote it.” Build at least the following minimal system.
6.1 Evaluation cycle (quarterly is recommended)
- Each quarter, check representative pages (top, list, detail, forms, account pages, etc.)
- Perform focused checks before releases that change major functionality
- Fix “critical failures” immediately; schedule others into the roadmap
6.2 Maintain a known-issues backlog
Manage issues using these four items:
- Where it occurs (page/function)
- Who it affects (keyboard, read-aloud, color vision, zoom, etc.)
- Whether an alternative exists
- Effort and priority (high/medium/low)
6.3 Inquiry handling flow (small, but mandatory)
A contact channel alone is not enough—you need the ability to respond.
- Receive → verify → provide alternative → decide on fix → share progress → update statement
If you define “who does what,” social responsibility becomes real organizational action.
7. Designing the Contact Channel: Accessibility Works When People Can Ask for Help
The contact channel is where users turn first. So design the contact channel itself carefully.
7.1 Multiple channels are ideal
- Email (stable, text-based)
- Form (strong error handling and input support)
- Phone (voice-based)
- If possible, text chat (consideration for hearing differences)
7.2 List “what we’d like you to share” in bullets
This improves reproducibility without raising user burden:
- Page name (or which screen)
- The action you were trying to take
- Device (PC/phone) and browser
- Read-aloud software (if used)
7.3 Sample canned responses
- On receipt:
“Thank you for contacting us. We will review the details and, if needed, provide information via an alternative method.” - Alternative provision:
“This material is currently being improved. We will send the same content in text format.” - Improvement plan:
“We aim to complete remediation by YYYY-MM. We will also record progress in our accessibility statement.”
8. How to Present an Improvement Plan That Gets Internal Buy-In
You don’t need a huge plan in the statement. But it helps both readers and internal stakeholders if “what we’ll prioritize” and “when we’ll review” are visible.
8.1 Mini roadmap example (plain text is enough)
- This quarter (0–3 months): unify form error messaging; improve keyboard navigation in primary menus
- Next (3–6 months): convert key PDFs to HTML; provide text versions for videos
- Later: push improvements for embedded third-party components; systematize components in a design system
8.2 Don’t promise perfection—promise the improvement system
Accessibility can’t be maintained by a one-time fix.
In the statement, promise “continuous evaluation and improvement,” and support it with operations (evaluation dates, update dates, and a contact channel). This is what builds trust.
9. The Accessibility of the Statement Page Itself
The statement page represents your organization’s stance. At minimum, ensure:
- Correct heading structure (h1 → h2 → h3)
- Text/background contrast (4.5:1)
- Links not identifiable by color alone (e.g., underline)
- Full access by keyboard
- Contact details (phone/email) are plain text and copyable
- Long pages have an opening summary and table of contents
10. Clear Value for Real People
- Blind/read-aloud users: can anticipate where issues may occur and reach alternatives quickly.
- People with hearing differences: can judge availability of captions and text versions.
- People with cognitive differences: reduced anxiety through clarity, plus clear contact info when stuck.
- Older adults: can seek assistance when zoom/operation becomes difficult.
- Organizations (PR/legal/ops): can fulfill accountability, standardize inquiry response, and agree on priorities more easily.
A statement is not “special treatment for the vulnerable.” It’s a system that ensures no one is left behind when they encounter barriers.
11. Accessibility Level Evaluation (What This Article Enables)
- Supports statement design and operations targeting WCAG 2.1 AA
- 1.3.1 Info and Relationships: structure via headings, lists, and sections
- 1.4.3 Contrast (Minimum): readability requirements for the statement page
- 2.4.1 Bypass Blocks: summary/TOC/headings for easier navigation
- 2.4.6 Headings and Labels: clear intent per section
- 3.1.5 Reading Level (practical): plain language, short sentences, concreteness
- 3.3.x (related): error identification and suggestion (if using forms)
- 4.1.2 Name, Role, Value (related): correct implementation of contact UI/forms
- Includes operations (evaluation date, update date, contact flow) so the organization can clearly state a system for “continuously aiming for AA.”
12. Conclusion: A Statement Is a Contract for Sustained Kindness
- An accessibility statement is not “we’re done”—it documents current status and promises for improvement.
- Required elements: purpose / scope / standards / conformance status / known issues / alternatives / last updated date.
- Known issues should follow: location → problem → impact → alternative → planned improvement.
- After publishing, use regular evaluation, backlog management, and inquiry flow to drive continuous improvement.
- Make the statement page itself accessible to avoid losing credibility.
Accessibility grows not from perfection, but from a commitment to not leaving people behind when they struggle.
An accessibility statement turns that commitment into a quiet but strong promise—so your organization’s kindness keeps reaching people, continuously.