web-a11y-review

Reviews frontend changes for accessibility regressions across semantics, keyboard behavior, forms, and ARIA.

Updated Sep 8, 2026
One-click install
npx skills add https://github.com/pedropenha/project-skills --skill web-a11y-review-pedropenha
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: web-a11y-review
Source: https://github.com/pedropenha/project-skills/tree/main/.agents/skills/web-a11y-review
Command: npx skills add https://github.com/pedropenha/project-skills --skill web-a11y-review-pedropenha

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Frontend changes often introduce accessibility regressions that go unnoticed until users are blocked. This Skill provides a structured review process that catches issues in semantics, keyboard navigation, forms, dynamic updates, styling, and ARIA before code is merged. ## Core Features & Use Cases - Structured Review Checklist: Covers semantic structure, keyboard operation, focus visibility, form labels and errors, dynamic update announcements, CSS contrast and reduced motion, and test coverage. - Severity-Ordered Findings Format: Reports findings with impact, smallest practical fix, and a regression check so issues are actionable and testable. - Use Case: Before merging a pull request that adds a modal dialog, run this review to verify the close control is focusable, Escape closes the dialog, and focus returns to the trigger, then receive a prioritized findings report. ## Quick Start Review the accessibility of the changes in this pull request and report any findings ordered by severity.

Frequently Asked Questions about web-a11y-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a pull request for accessibility issues?▼

Apply the review checklist covering semantic structure, keyboard operation, form labels, dynamic updates, CSS contrast, and ARIA state. Report findings ordered by severity with impact, the smallest practical fix, and a regression check for each issue.

What accessibility issues should be treated as high risk in code review?▼

Click-only behavior, focus traps, missing form labels, and unsynchronized ARIA state are treated as high risk. Behavioral blockers that prevent keyboard or assistive technology users from completing tasks take priority over stylistic concerns.

How should accessibility findings be written in a code review?▼

Each finding states severity and the affected file or component, then describes impact on users, the smallest practical fix, and a regression check. Specific, actionable, and testable findings are preferred over vague statements like improve accessibility.

Does accessibility review replace automated testing tools?▼

No, the checklist expects tests to include automation plus relevant manual smoke checks. Automated tools catch some issues, but keyboard-only flows, focus management, and screen reader behavior require manual verification.

What should I report if no accessibility issues are found?▼

State clearly that no issues were found and list residual testing gaps. This makes the review outcome explicit rather than leaving reviewers uncertain about coverage.