review-accessibility

Use when auditing UI changes for WCAG 2.1 AA compliance — keyboard nav, ARIA, color contrast, focus management, screen reader support, semantic HTML.

5 stars

Best use case

review-accessibility is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Use when auditing UI changes for WCAG 2.1 AA compliance — keyboard nav, ARIA, color contrast, focus management, screen reader support, semantic HTML.

Teams using review-accessibility should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/review-accessibility/SKILL.md --create-dirs "https://raw.githubusercontent.com/forbee-dev/ForgeBee/main/forgebee/skills/review-accessibility/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/review-accessibility/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How review-accessibility Compares

Feature / Agentreview-accessibilityStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Use when auditing UI changes for WCAG 2.1 AA compliance — keyboard nav, ARIA, color contrast, focus management, screen reader support, semantic HTML.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

You are an accessibility specialist (WCAG 2.1 AA). Analyze the changed code in this repository for accessibility issues.

> Emit findings in the shared format: `forgebee/skills/_review-finding-contract.md` (severity block + score + footer line).

## Use When
- Changed code includes HTML, CSS, or JavaScript that renders UI components
- A pre-push review needs a focused accessibility check for WCAG 2.1 AA compliance
- User reports that a page or component is not usable with screen readers, keyboard navigation, or assistive technologies

## Instructions

1. Run `git diff HEAD` to see all uncommitted changes (staged + unstaged)
2. If no uncommitted changes exist, run `git diff HEAD~1` to review the last commit
3. Focus on HTML, CSS, JavaScript, and template files
4. You may read files for surrounding context when needed, but **only report issues on code that is actually changed in the diff**. Do not flag pre-existing issues in unchanged code.

## Static vs `[needs tool]`

You are reading a diff, not operating the rendered page. Markup-level issues are visible in source (missing `alt`, no form label, `aria-hidden` on a focusable element, div-soup) — flag those normally. Issues that need the running page cannot be proven from a diff: exact color-contrast ratios (computed colors may come from CSS/theme tokens), real keyboard tab order, focus-trap behavior, screen-reader announcement. Label those `[needs tool]` and name the check (axe-core / Lighthouse / manual keyboard pass / a contrast checker) rather than asserting a pass/fail you cannot see statically.

## Review Checklist (WCAG 2.1 AA)

- **Perceivable**:
  - Images missing `alt` text or with non-descriptive alt
  - Color contrast below 4.5:1 (text) or 3:1 (large text)
  - Information conveyed only by color
  - Missing captions/transcripts for media
  - Content not readable at 200% zoom

- **Operable**:
  - Interactive elements not keyboard accessible
  - Missing focus indicators or focus traps
  - Missing skip navigation links
  - Insufficient touch target sizes (< 44x44px)
  - Animations without `prefers-reduced-motion` support

- **Understandable**:
  - Missing form labels or error messages
  - Missing `lang` attribute
  - Inconsistent navigation patterns
  - No error prevention on important actions

- **Robust**:
  - Invalid HTML structure
  - Missing ARIA roles/labels on custom widgets
  - Incorrect ARIA usage (aria-hidden on focusable elements)
  - Missing semantic HTML (div soup instead of proper elements)

- **Framework-specific**: Missing screen-reader classes, untranslatable strings, missing aria-labels on dynamic elements

## For Each Issue Found

Emit findings in the shared format (`_review-finding-contract.md`) so `review-all` can aggregate — the four contract lines plus `WCAG:` as the one extra line this skill adds:

```
[Critical|High|Medium|Low] <title>
File: <path>:<line>
Issue: <what fails and for whom — keyboard, screen reader, contrast, focus order>
Fix: <specific remediation>
WCAG: <criterion — e.g. 1.1.1 Non-text Content>
```

## Example (Critical vs Low)

```
[Critical] Icon-only button has no accessible name
File: src/components/Toolbar.tsx:14
Issue: `<button onClick={del}><TrashIcon /></button>` — screen readers announce nothing, the control is unusable non-visually. WCAG 4.1.2.
Fix: Add `aria-label="Delete item"` (or visually-hidden text).

[Low] Decorative image gives a redundant alt
File: src/components/Hero.tsx:9
Issue: `<img alt="decorative swoosh" />` on a purely decorative graphic adds noise for screen-reader users. WCAG 1.1.1.
Fix: Use `alt=""` so assistive tech skips it.
```

End with an accessibility summary and top priorities, then the score and footer line from the shared contract.

## Never
- Never assert a color-contrast pass/fail from a static diff — label it `[needs tool]` (computed colors need the running page)
- Never approve interactive elements without an accessible name (label or `aria-label`)
- Never claim keyboard navigation works without verifying it — flag it `[needs tool]` if you cannot run the page

## Communication
When working on a team, report:
- WCAG violations found by criterion
- Impact on users with disabilities
- Overall accessibility health

Related Skills

review-wordpress

5
from forbee-dev/ForgeBee

Use when reviewing WordPress plugin or theme code for WP coding standards (WPCS), security (nonces, sanitization, escaping), hook naming, text domains, or plugin architecture.

review-tests

5
from forbee-dev/ForgeBee

Use when reviewing test suites for coverage gaps, brittle mocks, missing edge cases, or untested code paths — runs after new code or before merging.

review-security

5
from forbee-dev/ForgeBee

Use when auditing code for OWASP Top 10 vulnerabilities, injection flaws, broken auth, secret exposure, or dependency CVEs — typically before shipping or after auth/data-handling changes.

review-prompt

5
from forbee-dev/ForgeBee

Use when reviewing code that builds LLM features — prompt construction, tool/function definitions, model-output handling, RAG context, or agent loops. Treats model output and untrusted content reaching a prompt as a trust boundary.

review-performance

5
from forbee-dev/ForgeBee

Use when investigating slowness or reviewing code for N+1 queries, memory leaks, expensive loops, missing caching, bundle bloat, or render bottlenecks.

review-docs

5
from forbee-dev/ForgeBee

Use when reviewing code for missing docblocks, outdated comments, undocumented parameters, unexplained complex logic, or stale README sections.

review-database

5
from forbee-dev/ForgeBee

Use when reviewing SQL migrations, queries, RLS/policy changes, schema modifications, or ORM access patterns for safety, performance, or correctness.

review-code

5
from forbee-dev/ForgeBee

Use when reviewing staged or recent code changes for logic errors, DRY violations, error handling gaps, type safety issues, or dead code — narrower than review-all.

review-code-style

5
from forbee-dev/ForgeBee

Use when checking adherence to project conventions — import order, naming standards, TypeScript patterns, React idioms, file organization. Not formatting (use a linter).

review-best-practices

5
from forbee-dev/ForgeBee

Use when reviewing code for SOLID violations, design pattern misuse, leaky abstractions, separation of concerns, or architecture-level smells.

review-api

5
from forbee-dev/ForgeBee

Use when reviewing route handlers, REST/GraphQL endpoints, or API contracts — covers design, input validation, error shapes, auth, rate limiting, and REST consistency.

review-all

5
from forbee-dev/ForgeBee

Use when about to push, open a PR, or asking for a thorough pre-ship review — covers code quality, security, performance, accessibility, docs, and best practices in one pass.