SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsreviewing-a11y

reviewing-a11y

Coding & development

View repository

Updated 10-16 00:06

About this skill

Japanese version (Japanese)

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.

  1. List the components that appear in the target by ARIA role (button, dialog, combobox, and so on).
  2. Use 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.
  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:

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.