
Accessibility Compliance
Implement WCAG 2.2 patterns and fix audit findings so web and mobile UIs work with keyboards and assistive tech.
Overview
Accessibility Compliance is an agent skill most often used in Build (also Ship) that implements WCAG 2.2 interfaces with ARIA, keyboard support, and assistive-technology patterns.
Install
npx skills add https://github.com/wshobson/agents --skill accessibility-complianceWhat is this skill?
- WCAG 2.2 framing across perceivable, operable, understandable, and robust principles
- ARIA roles, states, properties, and live region patterns
- Keyboard navigation, focus trapping, and focus management
- Accessible forms, labeling, reduced motion, and high-contrast preferences
- Mobile accessibility for iOS VoiceOver and Android TalkBack plus audit remediation
- WCAG 2.2 four principles: perceivable, operable, understandable, robust
Adoption & trust: 9.6k installs on skills.sh; 36.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your UI ships with keyboard traps, missing labels, or ARIA mistakes that fail audits and exclude disabled users.
Who is it for?
Indie devs building React, Vue, or mobile web UIs who need WCAG 2.2 Level AA guidance embedded in agent-assisted implementation or fixes.
Skip if: Legal certification sign-off or enterprise VPAT production without human accessibility specialists and device testing.
When should I use this skill?
Auditing accessibility, implementing ARIA patterns, building for screen readers, or ensuring inclusive user experiences.
What do I get? / Deliverables
Your components gain WCAG-oriented patterns, documented ARIA usage, and a clearer path to AA compliance before users hit production errors.
- Accessible component implementations
- Audit-oriented fix list aligned to WCAG violations
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Most accessibility work lands in Build while crafting UI, but the same skill applies again in Ship when auditing before release. Frontend is the canonical shelf because ARIA roles, focus management, and form labeling are implemented in client code.
Where it fits
Add proper roles and labelledby to a custom combobox before merging the settings page.
Run an accessibility audit pass on checkout and fix contrast and focus order before launch.
Verify keyboard paths and live regions on notification toasts ahead of a public release.
Remediate reported screen-reader breakage on help-center navigation without a full redesign.
How it compares
Implementation and audit guidance skill—not an automated Lighthouse subscription or one-click compliance certificate.
Common Questions / FAQ
Who is accessibility-compliance for?
Frontend-focused solo builders who own UX quality and must make web or mobile interfaces work for screen readers and keyboard-only users.
When should I use accessibility-compliance?
During Build while implementing components and forms; in Ship during review or security-minded launch prep when running accessibility audits and fixing violations.
Is accessibility-compliance safe to install?
It provides coding patterns only; review the Security Audits panel on this page and test changes in staging before production deploys.
SKILL.md
READMESKILL.md - Accessibility Compliance
# Accessibility Compliance Master accessibility implementation to create inclusive experiences that work for everyone, including users with disabilities. ## When to Use This Skill - Implementing WCAG 2.2 Level AA or AAA compliance - Building screen reader accessible interfaces - Adding keyboard navigation to interactive components - Implementing focus management and focus trapping - Creating accessible forms with proper labeling - Supporting reduced motion and high contrast preferences - Building mobile accessibility features (iOS VoiceOver, Android TalkBack) - Conducting accessibility audits and fixing violations ## Core Capabilities ### 1. WCAG 2.2 Guidelines - Perceivable: Content must be presentable in different ways - Operable: Interface must be navigable with keyboard and assistive tech - Understandable: Content and operation must be clear - Robust: Content must work with current and future assistive technologies ### 2. ARIA Patterns - Roles: Define element purpose (button, dialog, navigation) - States: Indicate current condition (expanded, selected, disabled) - Properties: Describe relationships and additional info (labelledby, describedby) - Live regions: Announce dynamic content changes ### 3. Keyboard Navigation - Focus order and tab sequence - Focus indicators and visible focus states - Keyboard shortcuts and hotkeys - Focus trapping for modals and dialogs ### 4. Screen Reader Support - Semantic HTML structure - Alternative text for images - Proper heading hierarchy - Skip links and landmarks ### 5. Mobile Accessibility - Touch target sizing (44x44dp minimum) - VoiceOver and TalkBack compatibility - Gesture alternatives - Dynamic Type support ## Quick Reference ### WCAG 2.2 Success Criteria Checklist | Level | Criterion | Description | | ----- | --------- | ---------------------------------------------------- | | A | 1.1.1 | Non-text content has text alternatives | | A | 1.3.1 | Info and relationships programmatically determinable | | A | 2.1.1 | All functionality keyboard accessible | | A | 2.4.1 | Skip to main content mechanism | | AA | 1.4.3 | Contrast ratio 4.5:1 (text), 3:1 (large text) | | AA | 1.4.11 | Non-text contrast 3:1 | | AA | 2.4.7 | Focus visible | | AA | 2.5.8 | Target size minimum 24x24px (NEW in 2.2) | | AAA | 1.4.6 | Enhanced contrast 7:1 | | AAA | 2.5.5 | Target size minimum 44x44px | ## Key Patterns ### Pattern 1: Accessible Button ```tsx interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> { variant?: "primary" | "secondary"; isLoading?: boolean; } function AccessibleButton({ children, variant = "primary", isLoading = false, disabled, ...props }: ButtonProps) { return ( <button // Disable when loading disabled={disabled || isLoading} // Announce loading state to screen readers aria-busy={isLoading} // Describe the button's current state aria-disabled={disabled || isLoading} className={cn( // Visible focus ring "focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-offset-2", // Minimum touch target size (44x44px) "min-h-[44px] min-w-[44px]", variant === "primary" && "bg-primary text-primary-foreground", (disabled || isLoading) && "opacity-50 cursor-not-allowed", )} {...props} > {isLoading ? ( <