reviewing-a11y · git:20261014.8dde2ea · 2026-10-14 · sha256 e79d1d7227221869

reviewing-a11y git:20261014.8dde2eaA

Immutable. This exact content never changes and is served at /api/v1/blob/e79d1d7227221869.

---
name: reviewing-a11y
description: Review accessibility of web pages, code implementations, design mockups, and specifications, then report severity-ranked issues and fixes. Use auditing-wcag instead for formal conformance decisions across all success criteria.
argument-hint: URL, file path, or Figma URL to review
allowed-tools: Read Grep Glob WebFetch Task mcp__playwright__browser_snapshot mcp__playwright__browser_navigate mcp__playwright__browser_click
---

[日本語版 (Japanese)](./SKILL.ja.md)

# Accessibility Review

Identify what the user wants reviewed, then perform the accessibility review by following the corresponding reference guide.

## Step 1: Identify Review Target

Analyze the user's request to determine the review target:

### Web Page (Live URL)
**Indicators:**
- User provides a URL starting with `http://` or `https://`
- User says "check this page", "review this site", "test this URL"
- User wants to review a deployed/live website

**Action:** Follow the page review guide

### Code Implementation
**Indicators:**
- User provides file paths (`.jsx`, `.tsx`, `.vue`, `.html`, `.js`, etc.)
- User says "review this component", "check my code", "look at this implementation"
- User mentions specific files or directories in the codebase
- User asks about static code analysis

**Action:** Follow the code review guide

### Design Mockup/Specification
**Indicators:**
- User provides Figma URL (figma.com/file/...)
- User shares image files (.png, .jpg, .pdf of designs)
- User says "review this design", "check this mockup", "look at this wireframe"
- User asks about design specifications or visual accessibility

**Action:** Follow the design review guide

### Ambiguous Cases
If unclear, ask the user:
```
I can review accessibility for:
1. **Live web pages** (provide URL) - I'll test the rendered page
2. **Code implementation** (provide file paths) - I'll analyze the source code
3. **Design mockups** (provide Figma URL or images) - I'll review visual designs

Which would you like me to review?
```

## Step 2: Look Up the Judgment Lines in the Knowledge Base

Once you identify the target, and before looking at the code or page, align your findings with [a11y-knowledge](../a11y-knowledge/SKILL.md).

1. List the components that appear in the target by ARIA role (button, dialog, combobox, and so on).
2. Use [index-by-component.md](../a11y-knowledge/references/index-by-component.md) to find the success criteria that apply to each role. When reviewing a layout or a whole page, also pick the "Whole page" and "Multiple pages" criteria from [index-by-criterion.md](../a11y-knowledge/references/index-by-criterion.md).
3. For each criterion found, read "Judgment lines" and "When building" in `../a11y-knowledge/references/criteria/<number>.md` before writing a finding. Do not report what the "Judgment lines" say does not apply.
4. When a finding is based on an **[Our interpretation]** judgment line (an operational interpretation), say so in the finding (for example, "[Our interpretation] judgment line; the project may override it"). **[Understanding]** judgment lines need no such note.

The knowledge base is referenced by the relative path `../a11y-knowledge/`. It resolves when installed as a plugin. When installed by symlinking individual skill directories, link `a11y-knowledge` as well. If it does not resolve, skip this step and write "knowledge base not consulted" in the report.

## Step 3: Load the Guide and Review

Once you identify the target, read the reference guide matching the user's language and execute its process directly.

### For Web Pages
```
Read the page review guide:
- English: references/page-review.md
- Japanese: references/page-review.ja.md

Follow the guide using available browser interaction, web retrieval, or user-provided content.
```

### For Code
```
Read the code review guide:
- English: references/code-review.md
- Japanese: references/code-review.ja.md

Follow the guide by inspecting the target files and related implementation.
```

### For Designs
```
Read the design review guide:
- English: references/design-review.md
- Japanese: references/design-review.ja.md

Follow the guide using available image, document, or Figma retrieval capabilities.
```

### When to Use Sub-agents

- Use sub-agents only when the user explicitly requests parallel review, specialist delegation, or division across multiple targets.
- Assign one target type to each agent and provide the relevant guide and target.
- Wait for every result, remove duplicates, and return one consolidated report.
- If sub-agents are unavailable, review the targets sequentially in this agent.

## Step 4: Return Results

When the review completes:
1. Present the findings to the user
2. Offer to review additional targets if needed
3. Suggest next steps (e.g., "Would you like me to review the code implementation next?")

## Important Notes

- **Always read the appropriate guide before starting the review**
- **Choose the language** (English or Japanese) based on the user's language
- **Distinguish evidence from gaps** and state what could not be verified
- **Don't mix review types** - use one guide per target type

## Example Workflows

### Example 1: User provides URL
```
User: "Review https://example.com for accessibility"

1. Identify: This is a web page (URL provided)
2. Look up: find the criteria in index-by-component and read "Judgment lines" and "When building"
3. Read: references/page-review.md
4. Execute: Inspect the page by following the guide
5. Return: Present findings
```

### Example 2: User provides file path
```
User: "Check src/components/Button.tsx for a11y issues"

1. Identify: This is code (file path provided)
2. Look up: find the criteria in index-by-component and read "Judgment lines" and "When building"
3. Read: references/code-review.md
4. Execute: Inspect the target and related code by following the guide
5. Return: Present findings
```

### Example 3: User provides Figma URL
```
User: "Review this design: https://figma.com/file/abc123"

1. Identify: This is a design (Figma URL)
2. Look up: find the criteria in index-by-component and read "Judgment lines" and "When building"
3. Read: references/design-review.md
4. Execute: Inspect the design by following the guide
5. Return: Present findings
```

## WCAG & Standards Reference

All reviews should reference:
- **WCAG 2.2**: https://www.w3.org/TR/WCAG22/
- **WAI-ARIA APG**: https://www.w3.org/WAI/ARIA/apg/
- **WCAG Quick Reference**: https://www.w3.org/WAI/WCAG22/quickref/

Common success criteria to reference:
- 1.1.1 Non-text Content (A)
- 1.3.1 Info and Relationships (A)
- 1.4.3 Contrast (Minimum) (AA)
- 2.1.1 Keyboard (A)
- 2.4.6 Headings and Labels (AA)
- 4.1.2 Name, Role, Value (A)

Do not turn missing evidence into a conclusive finding. List unsupported checks as manual verification.