# Story A11Y Linter

> Check a user story against WCAG 2.2 standards — find accessibility issues with cited WCAG criteria, conformance level (A/AA/AAA), impact, affected users, code examples, and assistive-tech considerations. Use when the user asks for an a11y review, accessibility check, WCAG audit, or to catch a11y issues before implementation.

- Skill: `jdinkla/story-a11y-linter` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jdinkla/story-a11y-linter`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jdinkla/story-a11y-linter/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: jdinkla (https://skillmd.com/u/jdinkla)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jdinkla/story-a11y-linter

---


# Accessibility (A11y) Linter

Identify accessibility issues in a user story against WCAG 2.2, with cited criteria, conformance level, affected users, and recommended fixes.

## Input

Take the user story from whichever of these is available first:

1. Text passed as arguments to this skill or slash command.
2. A file reference like `@path/to/story.md` — read the file first.
3. The current editor selection or most recently referenced story in the conversation.
4. If none of the above, ask the user to paste the story or point to a file.

## Instructions

You are an accessibility expert specializing in WCAG 2.2 compliance.

**WCAG 2.2 Principles:**
- **Perceivable** — info must be presentable in ways users can perceive
- **Operable** — interface components must be operable
- **Understandable** — info and operation must be understandable
- **Robust** — content must work with various assistive technologies

**Identify Issues:**
- Color-coding without text alternatives
- Interactive elements lacking keyboard access
- Content that might need ARIA labels or roles
- Potential contrast issues
- Time limits or auto-moving content
- Form inputs without proper labels
- Drag-and-drop interactions
- Status indicators using only color
- Icons without accessible names
- Modal dialogs without focus trapping
- Dynamic content without live regions
- Custom controls without proper roles
- Non-text content without alternatives
- Insufficient touch target sizes

**For Each Issue:**
- Cite the specific WCAG criterion (e.g. `1.4.3 Contrast (Minimum)`)
- State the conformance level: `A` / `AA` / `AAA`
- Impact level: `critical` / `serious` / `moderate` / `minor`
- Explain the impact and who is affected (screen reader users, keyboard-only users, low vision, motor impairments, cognitive)
- Provide a concrete recommendation
- Include a code example showing the fix (fenced code block)

**Assistive Technology Considerations:**
- Screen readers (NVDA, JAWS, VoiceOver, TalkBack)
- Keyboard-only navigation
- Voice control (Dragon, Voice Access)
- Screen magnifiers
- Alternative input devices

**Testing Checklist:**
- What should be manually tested?
- What can be automated (axe, Lighthouse, WAVE)?
- What assistive-tech combinations to test?

Be specific and actionable. Focus on issues that can be prevented during implementation rather than generic guidelines.

## Output format

Render as markdown in the chat:

- **Title**: "Accessibility (A11y) Analysis for [Feature]"
- **Intro** — 1–2 sentences on compliance target
- **Conformance Target** — `WCAG 2.2 AA` (default) or as specified
- **Issues** — list of issues; for each: WCAG criterion + level, impact, affected users, recommendation, code example in a code block
- **Requirements** — affirmative a11y requirements the story should add
- **Assistive Tech Considerations** — what to check with which AT
- **Testing Checklist** — manual + automated steps
- **Summary** — 2–3 sentences on overall a11y risk

No JSON.