What it does
Instead of publishing a generic legal-template statement, this works through the site's real accessibility posture (contrast checks, alt text coverage, keyboard navigation, known gaps) and drafts a statement that names what's actually true today, along with a contact path for visitors to report accessibility issues. Avoids the common failure mode of a statement claiming full compliance a site hasn't actually verified.
Install
This skill isn't packaged in an installable registry. It's a plain SKILL.md file you can copy directly. Copy it from the SKILL.md tab and save it at the path for your assistant:
Use it in your AI assistant
Claude Code
.claude/skills/accessibility-statement-writer/ (or ~/.claude/skills/accessibility-statement-writer/ for all projects)
GitHub Copilot (VS Code)
.github/skills/accessibility-statement-writer/
OpenAI Codex
.codex/skills/accessibility-statement-writer/
Cursor
.cursor/skills/accessibility-statement-writer/ (or ~/.cursor/skills/accessibility-statement-writer/ globally)
Compatibility
Any WordPress site. Most accurate when paired with the agent's own contrast and alt-text audit results as input rather than run in isolation.
The complete SKILL.md for this skill:
---
name: accessibility-statement-writer
description: Use when a user wants an accessibility statement page written or updated, mentions WCAG compliance disclosure, or needs to publish an accessibility contact/feedback process.
---
# Accessibility Statement Writer
## When to use
The user needs an accessibility statement page published (often for legal or policy reasons) and wants it to reflect the site's real, current state rather than a boilerplate claim of full compliance.
## Procedure
1. Gather what's actually known about the site's accessibility state: recent contrast checks, alt text coverage, keyboard navigation testing, known unresolved issues.
2. If no recent audit exists, run or request a basic pass (contrast, alt text, navigation) before drafting rather than writing from assumptions.
3. Draft the statement to name the target standard being aimed for (commonly WCAG 2.1 AA), what's currently in place, and any known gaps or areas still being worked on.
4. Include a clear, monitored contact method for visitors to report accessibility barriers they encounter, and a rough expectation for response.
5. Avoid absolute compliance claims ("fully accessible") unless that's been independently verified, use accurate language like "we are working toward" where appropriate.
6. Note a review date on the statement and flag that it should be revisited whenever the site undergoes a significant redesign.
## Guardrails
- Never claim a compliance level that hasn't actually been tested, an inaccurate statement is a bigger legal and trust risk than an honest, modest one.
- Treat this as a starting draft for legal or leadership review, not a final publish-ready document, especially for regulated organizations.