How is this different from a full accessibility audit?

It’s a lightweight triage that prioritizes high-signal issues using automated checks plus essential manual checks, not a comprehensive WCAG 2.x audit.

What compliance level does it target by default?

WCAG 2.2 AA by default, with guidance to adjust per project if needed.

What should I do if issues are found?

Escalate to a full audit for complex changes or critical blockers, fix the issues, then re-run the smoke check to confirm improvements.

accessibility-audit

npx machina-cli add skill NickCrew/claude-cortex/accessibility-audit --openclaw

Files (1)

SKILL.md

3.0 KB

Accessibility Audit Skill

Fast, high-signal accessibility triage for pages, components, or PRs. This is a lightweight check, not a full compliance audit.

When to Use This Skill

Quick accessibility triage before releases
Component-level a11y verification
PR review for accessibility regressions
Smoke checks for WCAG compliance
Validating keyboard navigation on new features

Quick Audit Checklist

1. Automated Snapshot (Recommended)

Run one of these automated tools first:

npx @axe-core/cli <url> - Quick axe-core scan
npx pa11y <url> --standard WCAG2AA - Pa11y audit
Lighthouse Accessibility score (Chrome DevTools > Lighthouse > Accessibility)

2. Keyboard Basics

Check	Expected
All interactive elements reachable via Tab	Yes
Focus indicator always visible	Yes
No keyboard traps	Yes
Logical tab order	Yes
Skip link works for long pages	Yes

3. Semantics and Labels

Check	Expected
Single, descriptive H1	Yes
Logical heading order (no large jumps)	Yes
Form inputs have visible labels or aria-label	Yes
Buttons and links have clear names	Yes
Images have meaningful alt text (or empty for decorative)	Yes

4. Visual Contrast

Element	Minimum Ratio
Normal text	4.5:1
Large text (18pt+ or 14pt bold+)	3:1
UI components (inputs, buttons, focus rings)	3:1

5. Motion and Updates

Check	Expected
Respects `prefers-reduced-motion`	Yes
Dynamic updates announced (aria-live)	Yes

Output Format

After running the audit, report findings as:

## Accessibility Audit: [Component/Page Name]

### Result: [Pass | Needs Fixes | Escalate to Full Audit]

### Findings

| Severity | Issue | Location | Fix Guidance |
|----------|-------|----------|--------------|
| Critical | [Description] | [Selector/Line] | [How to fix] |
| Major | [Description] | [Selector/Line] | [How to fix] |
| Minor | [Description] | [Selector/Line] | [How to fix] |

### Escalation Recommendation
[If applicable, explain why a full audit is needed]

Escalate to Full Audit When

New or changed navigation structure
Complex forms or authentication flows
Custom widgets or advanced interactions (modals, accordions, tabs)
Public releases or compliance requirements
Significant page structure changes
Failed automated scans with multiple critical issues

Notes

This smoke check targets WCAG 2.2 AA by default
If a different compliance level is required, state it explicitly
Automated tools catch ~30-40% of issues; manual testing is essential
Test with actual screen readers (VoiceOver, NVDA) for comprehensive coverage

Source

git clone https://github.com/NickCrew/claude-cortex/blob/main/skills/accessibility-audit/SKILL.mdView on GitHub

Overview

Provides fast, high-signal accessibility triage for pages, components, or PRs. It is a lightweight check designed for quick releases and PR reviews, targeting WCAG 2.2 AA rather than a full compliance audit.

How This Skill Works

Start with automated snapshot checks (axe-core, Pa11y, or Lighthouse) to surface issues quickly. Then perform keyboard basics, semantics and labeling, and visual contrast checks, plus motion-related validations. The output prioritizes findings to guide rapid fixes during development and PR review.

When to Use It

Quick accessibility triage before releases
Component-level a11y verification
PR review for accessibility regressions
Smoke checks for WCAG compliance
Validating keyboard navigation on new features

Quick Start

Step 1: Run automated snapshot checks (e.g., npx @axe-core/cli <url>, npx pa11y <url> --standard WCAG2AA, or Lighthouse Accessibility score)
Step 2: Validate Keyboard Basics (tab accessibility, visible focus, no traps, logical tab order, skip link functionality)
Step 3: Review Semantics, Labels, Contrast, and Motion (single descriptive H1, proper labeling, meaningful alt text, contrast ratios, and prefers-reduced-motion)

Best Practices

Run automated snapshot tools (axe-core, Pa11y, or Lighthouse) first to surface high-signal issues
Verify keyboard accessibility: all interactive elements reachable via Tab, visible focus, no traps, logical tab order, and working skip links
Check semantics and labels: ensure descriptive H1, proper heading order, visible labels for inputs, clear names for buttons/links, and meaningful alt text
Assess visual contrast: meet 4.5:1 for normal text, 3:1 for large text and UI components
Consider motion and updates: respect prefers-reduced-motion and ensure aria-live announcements where appropriate

Example Use Cases

Smoke test on a PR introducing a new modal dialog, verifying focus trapping, labeling, and ARIA semantics
Component-level a11y verification for a new tabbed interface with proper heading order and accessible names
Quick WCAG 2.2 AA check on a landing page before release focusing on form accessibility and alt text
PR review for keyboard navigation in a complex form with visible focus indicators and skip links
Accessible updates verification after a UI upgrade, ensuring contrast and motion preferences are respected

Frequently Asked Questions

Add this skill to your agents