New to Claude Skills? Learn how to install them β†’

anthropics on GitHub

Accessibility Review

OfficialFree

Ensure your designs meet WCAG 2.1 AA standards.

Get this skill

Free Β· Opens the source repo

What Accessibility Review does

The Accessibility Review skill allows designers and developers to perform automated audits on their designs or web pages to ensure compliance with WCAG 2.1 AA accessibility standards. By simply invoking the skill with commands like "audit accessibility" or "check a11y," users can quickly assess various aspects of accessibility, including color contrast, keyboard navigation, touch target sizes, and screen reader behavior. This skill is particularly useful during the design review process, where accessibility is often overlooked before handoff to development.

The skill operates by providing a structured output that highlights potential accessibility issues categorized under the four principles of accessibility: Perceivable, Operable, Understandable, and Robust. Each section of the audit report details specific issues, their severity, and recommendations for fixes, making it easier for teams to prioritize and address accessibility concerns effectively. For instance, it identifies common issues such as insufficient color contrast, missing alt text, and keyboard navigation problems, which are critical for creating inclusive digital experiences.

In addition to the automated checks, the skill encourages manual testing with assistive technologies like screen readers to catch issues that automated scans may miss. This dual approach ensures a more comprehensive evaluation of accessibility, which is essential for meeting the needs of all users, including those with disabilities. The skill is ideal for design teams looking to integrate accessibility into their workflow, ensuring that their products are usable by everyone.

By using this skill, teams can foster a culture of accessibility within their organization, leading to better user experiences and compliance with legal standards. It serves as a practical tool for anyone involved in the design and development process, from UX/UI designers to front-end developers, ensuring that accessibility is a key consideration from the outset.

When to use it

Use this skill during the design review phase to identify and rectify accessibility issues before finalizing a project.

When not to use it

This skill may not be suitable for comprehensive accessibility evaluations, as it relies on automated checks and should be complemented with manual testing.

What you can build with it

Design Review

Use the skill during design reviews to ensure that accessibility standards are met before handoff to developers.

Pre-launch Checks

Run an accessibility audit on your web page before launch to catch any compliance issues that could affect user experience.

Team Collaboration

Integrate the skill into your team's workflow to foster discussions around accessibility and prioritize fixes based on audit findings.

How to install Accessibility Review

View source

1. Install with the skills CLI

npx skills add anthropics/knowledge-work-plugins/accessibility-review --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by anthropics

/accessibility-review

If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Audit a design or page for WCAG 2.1 AA accessibility compliance.

Usage

/accessibility-review $ARGUMENTS

Audit for accessibility: @$1

WCAG 2.1 AA Quick Reference

Perceivable

  • 1.1.1 Non-text content has alt text
  • 1.3.1 Info and structure conveyed semantically
  • 1.4.3 Contrast ratio >= 4.5:1 (normal text), >= 3:1 (large text)
  • 1.4.11 Non-text contrast >= 3:1 (UI components, graphics)

Operable

  • 2.1.1 All functionality available via keyboard
  • 2.4.3 Logical focus order
  • 2.4.7 Visible focus indicator
  • 2.5.5 Touch target >= 44x44 CSS pixels

Understandable

  • 3.2.1 Predictable on focus (no unexpected changes)
  • 3.3.1 Error identification (describe the error)
  • 3.3.2 Labels or instructions for inputs

Robust

  • 4.1.2 Name, role, value for all UI components

Common Issues

  1. Insufficient color contrast
  2. Missing form labels
  3. No keyboard access to interactive elements
  4. Missing alt text on meaningful images
  5. Focus traps in modals
  6. Missing ARIA landmarks
  7. Auto-playing media without controls
  8. Time limits without extension options

Testing Approach

  1. Automated scan (catches ~30% of issues)
  2. Keyboard-only navigation
  3. Screen reader testing (VoiceOver, NVDA)
  4. Color contrast verification
  5. Zoom to 200% β€” does layout break?

Output

## Accessibility Audit: [Design/Page Name]
**Standard:** WCAG 2.1 AA | **Date:** [Date]

### Summary
**Issues found:** [X] | **Critical:** [X] | **Major:** [X] | **Minor:** [X]

### Findings

#### Perceivable
| # | Issue | WCAG Criterion | Severity | Recommendation |
|---|-------|---------------|----------|----------------|
| 1 | [Issue] | [1.4.3 Contrast] | πŸ”΄ Critical | [Fix] |

#### Operable
| # | Issue | WCAG Criterion | Severity | Recommendation |
|---|-------|---------------|----------|----------------|
| 1 | [Issue] | [2.1.1 Keyboard] | 🟑 Major | [Fix] |

#### Understandable
| # | Issue | WCAG Criterion | Severity | Recommendation |
|---|-------|---------------|----------|----------------|
| 1 | [Issue] | [3.3.2 Labels] | 🟒 Minor | [Fix] |

#### Robust
| # | Issue | WCAG Criterion | Severity | Recommendation |
|---|-------|---------------|----------|----------------|
| 1 | [Issue] | [4.1.2 Name, Role, Value] | 🟑 Major | [Fix] |

### Color Contrast Check
| Element | Foreground | Background | Ratio | Required | Pass? |
|---------|-----------|------------|-------|----------|-------|
| [Body text] | [color] | [color] | [X]:1 | 4.5:1 | βœ…/❌ |

### Keyboard Navigation
| Element | Tab Order | Enter/Space | Escape | Arrow Keys |
|---------|-----------|-------------|--------|------------|
| [Element] | [Order] | [Behavior] | [Behavior] | [Behavior] |

### Screen Reader
| Element | Announced As | Issue |
|---------|-------------|-------|
| [Element] | [What SR says] | [Problem if any] |

### Priority Fixes
1. **[Critical fix]** β€” Affects [who] and blocks [what]
2. **[Major fix]** β€” Improves [what] for [who]
3. **[Minor fix]** β€” Nice to have

If Connectors Available

If ~~design tool is connected:

  • Inspect color values, font sizes, and touch targets directly from Figma
  • Check component ARIA roles and keyboard behavior in the design spec

If ~~project tracker is connected:

  • Create tickets for each accessibility finding with severity and WCAG criterion
  • Link findings to existing accessibility remediation epics

Tips

  1. Start with contrast and keyboard β€” These catch the most common and impactful issues.
  2. Test with real assistive technology β€” My audit is a great start, but manual testing with VoiceOver/NVDA catches things I can't.
  3. Prioritize by impact β€” Fix issues that block users first, polish later.

Frequently asked questions about Accessibility Review

Similar skills