Accessibility
Ship web UIs that meet WCAG 2.1 AA so keyboard and screen-reader users can complete flows without rework after launch.
Overview
Accessibility is an agent skill most often used in Build (also Ship testing and review) that guides WCAG 2.1 AA implementation with semantic HTML, ARIA, keyboard navigation, and screen reader patterns.
Install
npx skills add https://github.com/jezweb/claude-skills --skill accessibilityWhat is this skill?
- WCAG 2.1 Level AA patterns: semantic landmarks, heading hierarchy, and labeled forms with associated errors
- Documented contrast targets—4.5:1 normal text and 3:1 UI/focus—and visible focus outlines (e.g. 0.0625rem ring)
- Keyboard and pointer coverage: skip links, focus traps for modals/menus, tab order, and no keyboard traps
- ARIA live regions, button vs link semantics, alt text rules, and screen-reader-friendly status announcements
- 4-step quick checklist plus expanded pre-launch audit list (50+ items) for manual and tooling-assisted review
- WCAG 2.1 Level AA target with 4.5:1 text and 3:1 UI/focus contrast guidance
- 4-step quick accessibility checklist plus 50+ item expanded audit checklist
- Documented 0.0625rem minimum focus outline pattern for visible focus indicators
Adoption & trust: 511 installs on skills.sh; 841 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your UI looks fine visually but fails keyboard traversal, contrast ratios, or screen reader announcements—and you keep patching the same focus and label bugs.
Who is it for?
Indie builders shipping marketing sites, SaaS dashboards, or content apps who need actionable WCAG 2.1 AA recipes and error-driven fixes in the agent loop.
Skip if: Backend-only APIs with no UI, teams seeking a certified legal compliance sign-off without manual testing, or projects scoped exclusively to WCAG AAA specialist remediation with no implementation work.
When should I use this skill?
Implementing accessible interfaces, fixing screen reader or keyboard navigation issues, or troubleshooting focus outline missing, aria-label required, and insufficient contrast.
What do I get? / Deliverables
You get production-oriented WCAG 2.1 AA patterns, checklists, and fixes for forms, modals, and navigation so the interface is operable by keyboard and assistive tech before you ship.
- WCAG-aligned semantic markup and ARIA patterns for common widgets
- Contrast- and focus-compliant CSS guidance applied to components
- Completed quick or full accessibility checklist suitable for pre-ship QA
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Accessibility is implemented while crafting markup, styles, and interactive components—the canonical home for semantic HTML, ARIA, and focus behavior is the frontend build shelf. The skill’s patterns target component markup, CSS contrast, keyboard order, and client-side focus traps—core frontend implementation work rather than infra or distribution.
Where it fits
Wire signup and checkout forms with explicit labels, aria-describedby errors, and 4.5:1 text contrast before merging.
Add skip links, landmark regions, and a modal focus trap so marketing pages and dialogs tab in a predictable order.
Run the 4-step quick checklist and expanded audit list with keyboard-only traversal and screen reader spot checks pre-release.
Triage lighthouse or axe findings plus agent-reported “can’t tab to element” bugs into semantic HTML and ARIA fixes.
Validate landing page hero contrast and heading hierarchy on a throwaway prototype before committing to full build.
How it compares
A structured implementation and audit playbook for WCAG AA—not a drop-in MCP server or a single automated scanner score without keyboard and screen-reader verification.
Common Questions / FAQ
Who is accessibility for?
Solo and indie developers using Claude Code, Cursor, or similar agents to build or fix web frontends when WCAG, keyboard, or screen reader issues show up in implementation or QA.
When should I use accessibility?
During Build frontend work on forms, modals, and navigation; during Ship testing when running the quick or full checklist; and during Ship review when triaging focus, contrast, and ARIA errors before launch.
Is accessibility safe to install?
It is documentation-style procedural guidance from the jezweb/claude-skills repo (MIT); review the Security Audits panel on this Prism page and your org’s policy before pulling third-party skills into agent workflows.
SKILL.md
READMESKILL.md - Accessibility
{ "name": "accessibility", "description": "Build WCAG 2.1 AA compliant websites with semantic HTML, proper ARIA, focus management, and screen reader support. Includes color contrast (4.5:1 text), keyboard navigation, form labels, and live regions. Use when implementing accessible interfaces, fixing screen reader issues, keyboard navigation, or troubleshooting focus outline missing, aria-label required, insufficient contrast.", "version": "1.0.0", "author": { "name": "Jeremy Dawes", "email": "jeremy@jezweb.net" }, "license": "MIT", "repository": "https://github.com/jezweb/claude-skills", "keywords": [], "agents": "./agents/" } # Web Accessibility (WCAG 2.1 AA) **Status**: Production Ready ✅ **Last Updated**: 2026-01-14 **Production Tested**: Framework-agnostic patterns used across multiple production sites --- ## Auto-Trigger Keywords Claude Code automatically discovers this skill when you mention: ### Primary Keywords - accessibility - a11y - wcag - screen reader - keyboard navigation - semantic html - aria - focus management ### Secondary Keywords - accessible forms - color contrast - alt text - focus trap - aria-label - aria-live - skip links - focus indicators - tab order - heading hierarchy - form labels - screen reader support ### Error-Based Keywords - "focus outline missing" - "insufficient contrast" - "aria-label required" - "keyboard trap" - "screen reader not announcing" - "can't tab to element" - "focus not visible" - "missing alt text" - "form label missing" - "heading level skipped" - "color contrast too low" - "not keyboard accessible" --- ## What This Skill Does Build fully accessible web interfaces that meet WCAG 2.1 Level AA standards with semantic HTML, proper ARIA implementation, and comprehensive keyboard support. ### Core Capabilities ✅ **Semantic HTML guidance** - Choose the right element for every purpose ✅ **ARIA patterns** - When and how to use ARIA roles, states, properties ✅ **Focus management** - Focus traps, restoration, skip links, visible indicators ✅ **Color contrast** - 4.5:1 text, 3:1 UI component ratios with testing ✅ **Form accessibility** - Labels, validation, error announcements ✅ **Keyboard navigation** - Full keyboard support for all interactions ✅ **Screen reader testing** - NVDA/VoiceOver testing workflows ✅ **Automated auditing** - a11y-auditor agent for violation detection --- ## Known Issues This Skill Prevents | Issue | Why It Happens | Source | How Skill Fixes It | |-------|---------------|---------|-------------------| | Missing focus indicators | CSS reset removes outlines | WCAG 2.4.7 | Provides focus-visible patterns | | Insufficient contrast | Light gray on white | WCAG 1.4.3 | Contrast checker workflow + ratios | | Missing alt text | Forgotten or thought optional | WCAG 1.1.1 | Alt text decision tree | | Keyboard navigation broken | div onClick instead of button | WCAG 2.1.1 | Semantic element guide | | Form inputs without labels | Using placeholder as label | WCAG 3.3.2 | Label association patterns | | Skipped heading levels | Visual styling instead of semantics | WCAG 1.3.1 | Heading hierarchy rules | | No focus trap in dialogs | Not implemented | WCAG 2.4.3 | Complete dialog pattern | | Missing aria-live updates | Dynamic content without announcement | WCAG 4.1.3 | Live region patterns | | Color-only information | Red text for errors | WCAG 1.4.1 | Multi-sensory patterns | | Non-descriptive links | "Click here" text | WCAG 2.4.4 | Link text guidelines | | Auto-playing media | Autoplay without controls | WCAG 1.4.2 | Media control patterns | | Inaccessible custom controls | divs without ARIA | WCAG 4.1.2 | Complete ARIA implementations | --- ## When to Use This Skill ### ✅ Use When: - Building any web interface (accessibility is not optional) - Implementing forms with validation - Creating dialogs, menus, tabs, accordions - Adding dynamic content updates - Troubleshooting keyboard navigation issues - Fixing screen reader compat