
Accessibility
Run WCAG 2.2–aligned accessibility audits and get concrete HTML/CSS/ARIA fixes before you ship a solo-built web UI.
Overview
Accessibility is an agent skill most often used in Ship review (also Build frontend, Ship launch) that audits and improves web UIs against WCAG 2.2 and Lighthouse-style accessibility checks.
Install
npx skills add https://github.com/addyosmani/web-quality-skills --skill accessibilityWhat is this skill?
- Maps fixes to WCAG 2.2 principles (Perceivable, Operable, Understandable, Robust) with A, AA, and AAA conformance target
- Copy-paste HTML patterns for alt text, headings, forms, tables, ARIA landmarks, live regions, and focus management
- Lighthouse-aligned audit themes: document structure, ARIA, forms, images, tables, language, contrast, and assistive-tech
- Testing playbook with axe, WAVE, Lighthouse, manual keyboard/screen-reader passes, and high-contrast/zoom checks
- End-of-skill quick checklist covering skip links, modals, touch targets, reduced motion, and error identification
- Based on WCAG 2.2 with conformance levels A, AA, and AAA
- Skill metadata version 1.1 (web-quality-skills author)
- Includes a multi-section Lighthouse accessibility audit mapping plus a condensed pre-ship quick checklist
Adoption & trust: 25k installs on skills.sh; 2.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to ship a web product but lack a systematic WCAG checklist, so keyboard users and screen-reader users may hit broken focus, missing labels, or illegal ARIA without you noticing.
Who is it for?
Solo builders with HTML/React/Vue pages who need a structured a11y audit and remediation snippets before legal or customer pressure on WCAG AA.
Skip if: Pure backend APIs, native mobile-only codebases with no web UI, or teams that already completed a formal third-party WCAG certification and only need tooling integration.
When should I use this skill?
Asked to improve accessibility, run an a11y audit, achieve WCAG compliance, add screen reader support, fix keyboard navigation, or make a interface accessible.
What do I get? / Deliverables
You get prioritized Perceivable–Operable–Understandable–Robust fixes, test steps with axe/WAVE/Lighthouse, and a quick pre-ship checklist you can apply file-by-file in your repo.
- WCAG 2.2–aligned issue list grouped by Perceivable, Operable, Understandable, and Robust
- Concrete markup and ARIA remediation snippets for the cited components
- Manual and automated test steps plus the skill’s quick accessibility checklist
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Accessibility is a pre-launch quality gate: the skill is framed as audit-and-fix work that belongs on the ship shelf with code review and compliance checks, not only while drafting components. Review is where solo builders validate POUR conformance, Lighthouse-style failures, and keyboard/screen-reader behavior against an existing codebase or page.
Where it fits
Implement labelled form fields, dialog focus traps, and 44px touch targets while you build the checkout UI.
Walk Lighthouse-style categories on a PR and turn failures into concrete HTML and ARIA patches.
Run the quick checklist (skip link, lang attribute, error text) on the production marketing URL before announce day.
Improve semantic headings, page titles, and document language so crawlers and assistive tech get the same clear structure.
How it compares
Use this skill package for agent-guided WCAG remediation in your repo—not as a substitute for running axe or Lighthouse in CI or a dedicated a11y SaaS dashboard.
Common Questions / FAQ
Who is accessibility for?
It is for solo and indie builders shipping web interfaces in Claude Code, Cursor, Codex, or similar agents who want WCAG 2.2-oriented guidance without memorizing the full specification.
When should I use accessibility?
Use it when you ask to improve accessibility, run an a11y audit, meet WCAG compliance, add screen reader support, or fix keyboard navigation—during Build frontend work, Ship review before merge, and Ship launch prep before customers hit production URLs.
Is accessibility safe to install?
It is reference documentation for auditing markup in your project; review the Security Audits panel on this Prism page for the ingested package signals before you enable it in agents with broad file access.
SKILL.md
READMESKILL.md - Accessibility
# Accessibility (a11y) Comprehensive accessibility guidelines based on WCAG 2.2 and Lighthouse accessibility audits. Goal: make content usable by everyone, including people with disabilities. ## WCAG Principles: POUR | Principle | Description | |-----------|-------------| | **P**erceivable | Content can be perceived through different senses | | **O**perable | Interface can be operated by all users | | **U**nderstandable | Content and interface are understandable | | **R**obust | Content works with assistive technologies | ## Conformance levels | Level | Requirement | Target | |-------|-------------|--------| | **A** | Minimum accessibility | Must pass | | **AA** | Standard compliance | Should pass (legal requirement in many jurisdictions) | | **AAA** | Enhanced accessibility | Nice to have | --- ## Perceivable ### Text alternatives (1.1) **Images require alt text:** ```html <!-- ❌ Missing alt --> <img src="chart.png"> <!-- ✅ Descriptive alt --> <img src="chart.png" alt="Bar chart showing 40% increase in Q3 sales"> <!-- ✅ Decorative image (empty alt) --> <img src="decorative-border.png" alt="" role="presentation"> <!-- ✅ Complex image with longer description --> <figure> <img src="infographic.png" alt="2024 market trends infographic" aria-describedby="infographic-desc"> <figcaption id="infographic-desc"> <!-- Detailed description --> </figcaption> </figure> ``` **Icon buttons need accessible names:** ```html <!-- ❌ No accessible name --> <button><svg><!-- menu icon --></svg></button> <!-- ✅ Using aria-label --> <button aria-label="Open menu"> <svg aria-hidden="true"><!-- menu icon --></svg> </button> <!-- ✅ Using visually hidden text --> <button> <svg aria-hidden="true"><!-- menu icon --></svg> <span class="visually-hidden">Open menu</span> </button> ``` **Visually hidden class:** ```css .visually-hidden { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } ``` ### Color contrast (1.4.3, 1.4.6) | Text Size | AA minimum | AAA enhanced | |-----------|------------|--------------| | Normal text (< 18px / < 14px bold) | 4.5:1 | 7:1 | | Large text (≥ 18px / ≥ 14px bold) | 3:1 | 4.5:1 | | UI components & graphics | 3:1 | 3:1 | ```css /* ❌ Low contrast (2.5:1) */ .low-contrast { color: #999; background: #fff; } /* ✅ Sufficient contrast (7:1) */ .high-contrast { color: #333; background: #fff; } /* ✅ Focus states need contrast too (3:1 against background, WCAG 1.4.11) */ :focus-visible { outline: 2px solid currentColor; outline-offset: 2px; } ``` **Don't rely on color alone:** ```html <!-- ❌ Only color indicates error --> <input class="error-border"> <style>.error-border { border-color: red; }</style> <!-- ✅ Color + icon + text --> <div class="field-error"> <input aria-invalid="true" aria-describedby="email-error"> <span id="email-error" class="error-message"> <svg aria-hidden="true"><!-- error icon --></svg> Please enter a valid email address </span> </div> ``` ### Media alternatives (1.2) ```html <!-- Video with captions --> <video controls> <source src="video.mp4" type="video/mp4"> <track kind="captions" src="captions.vtt" srclang="en" label="English" default> <track kind="descriptions" src="descriptions.vtt" srclang="en" label="Descriptions"> </video> <!-- Audio with transcript --> <audio controls> <source src="podcast.mp3" type="audio/mp3"> </audio> <details> <summary>Transcript</summary> <p>Full transcript text...</p> </details> ``` --- ## Operable ### Keyboard accessible (2.1) **All functionality must be keyboar