reviewer

Audits components, pages, and live websites for WCAG 2.1 accessibility compliance.

Updated Mar 28, 2026
One-click install
npx skills add https://github.com/po4yka/blog --skill reviewer-po4yka
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reviewer
Source: https://github.com/po4yka/blog/tree/main/.agents/skills/accesslint-reviewer
Command: npx skills add https://github.com/po4yka/blog --skill reviewer-po4yka

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Manually auditing code for accessibility violations is slow and error-prone, and teams often ship components that fail WCAG 2.1 criteria for keyboard users, screen reader users, and people with low vision. This Skill performs structured, multi-step accessibility audits of files, directories, entire codebases, or live URLs and produces prioritized, actionable reports. ## Core Features & Use Cases - Multi-scope audits: Analyze a single file, a directory, an entire codebase, or a live website via browser tools, with dependency tracing up to 2-3 levels deep. - WCAG 2.1 coverage: Checks Level A and AA criteria including contrast, keyboard traps, focus visibility, ARIA roles, form labels, and error identification, delegating to sibling skills for contrast, use-of-color, and link-purpose analysis. - Prioritized reporting: Groups findings into Critical, High, and Medium issues with file:line locations, impact descriptions, and concrete code fixes, plus positive findings. - GitHub issue creation: Optionally creates labeled GitHub issues via the gh CLI, with individual issues for critical findings and grouped checklist issues for lower priorities, always requiring explicit user approval. - Use Case: Point it at your React component library before a release to catch missing focus traps in modals, insufficient button contrast, and unlabeled form fields, then file tracked issues for each violation. ## Quick Start Audit the src/components directory for WCAG 2.1 accessibility violations and generate a prioritized report.

Frequently Asked Questions about reviewer

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

FAQPage Schema
How do I audit my codebase for WCAG accessibility violations?

Provide a file path, directory, or no argument to audit the entire codebase. The reviewer reads target files, follows imports up to 2-3 levels deep, checks WCAG 2.1 Level A and AA criteria, and outputs a prioritized report with file:line locations and code fixes.

How do I check accessibility of a live website?

Pass a URL and the reviewer opens it in a browser, captures the accessibility tree snapshot, extracts computed colors and styles via JavaScript, checks console messages for ARIA errors, and runs contrast, use-of-color, and link-purpose analysis on the rendered output.

What WCAG criteria does an accessibility code review cover?

The audit covers WCAG 2.1 Level A and AA criteria including non-text content, contrast minimums, keyboard access and traps, focus order and visibility, error identification, form labels, name-role-value, and status messages via live regions.

Can accessibility audit findings be turned into GitHub issues?

Yes, if the gh CLI is installed and authenticated. After the audit, the reviewer proposes individual issues for critical and high findings and grouped checklist issues for medium and low ones, creating them only after explicit user approval.

What are the limitations of automated accessibility testing?

Automated audits cannot judge screen reader announcement quality, content clarity, error message helpfulness, or complex visual contrast. The reviewer flags these cases for manual testing rather than reporting them as verified violations.