git:20261014.8dde2ea to git:20261030.021354a

19 added, 131 removed. Audit A to A.

---

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.

+ Identify the review target, find accessibility issues by following the matching reference guide, and report them by severity.

## 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

+ | Target | Indicators | Guide |

+ |---|---|---|

+ | Web page | A `http://` / `https://` URL, a deployed page | `references/page-review.md` |

+ | Code | File paths or directories (`.tsx`, `.vue`, `.html`, etc.), component names | `references/code-review.md` |

+ | Design | A Figma URL (`figma.com/design/`, `/file/`, `/proto/`, `/board/`), design images or PDFs, specifications | `references/design-review.md` |

- Which would you like me to review?

- ```

+ If you cannot decide, ask in one line whether to review a URL, file paths, or a design.

## 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

+ Read the guide from the Step 1 table in the user's language (`.ja.md` for Japanese, `.md` for English) and execute its process in this agent. Use one guide per target type; do not mix them.

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

- ```

+ Use sub-agents only when the user explicitly requests parallel review, delegation, or division across multiple targets. Give each agent one target type with its guide and target, wait for every result, remove duplicates, and return one report. If sub-agents are unavailable, review the targets sequentially.

- ### For Designs

- ```

- Read the design review guide:

- - English: references/design-review.md

- - Japanese: references/design-review.ja.md

+ ## Severity

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

- ```

+ All guides assign severity with this table. Severity reflects the impact on users and is independent of the WCAG level (A/AA).

- ### When to Use Sub-agents

+ | Severity | Definition | Example patterns |

+ |---|---|---|

+ | **Critical** | Users cannot operate or get the information at all | Informative image without an alternative, icon-only button without a name, input without an associated label, click-only or unfocusable controls, keyboard trap, `aria-labelledby` pointing to a non-existent ID, important information hidden with `display:none` or `aria-hidden="true"`, errors shown by color alone |

+ | **Major** | Possible but with significant difficulty | Missing or broken heading structure, missing or duplicate landmarks, wrong role or invalid `aria-*` values, focus order far from visual order, links or buttons that only say "click here" or "details", tables missing `th` / `scope`, missing page language (3.1.1), insufficient contrast |

+ | **Minor** | Possible with room for improvement | ARIA-built part that could be a native element (name, role, and keyboard operation already met), redundant ARIA duplicating native semantics, no skip link (when headings or landmarks let users bypass blocks), minor heading level inconsistencies, best practices that are not WCAG requirements |

- - 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.

+ Mark findings that are not WCAG requirements as "best practice" and do not attach a success criterion.

## 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.

+ 1. Present the findings in the guide's output format. Separate what was verified from what could not be verified (sent to manual verification). Do not turn missing evidence into a conclusive finding.

+ 2. If useful, offer to review another target type (e.g., "Would you like me to review the code implementation next?").