Accessibility
Ship WCAG 2.2 AA–compliant web and native UI by mapping components to semantic ARIA, traits, and focus behavior before and after you code.
Overview
Accessibility is an agent skill most often used in Build (also Ship review, Ship testing) that implements and audits WCAG 2.2 Level AA using semantic ARIA and native accessibility traits for Web, iOS, and Android.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill accessibilityWhat is this skill?
- Applies WCAG 2.2 Level AA using POUR (Perceivable, Operable, Understandable, Robust)
- Step 1 workflow: identify component role, then map to native semantics and the accessibility tree
- Covers labeling and hints via aria-label, accessibilityLabel, and contentDescription
- Implements newer WCAG 2.2 rules such as Target Size (Minimum) and Focus Appearance
- Supports Web, iOS, and Android specs, audits, and technical attribute mapping
- Targets WCAG 2.2 Level AA success criteria
- Explicitly covers Target Size (Minimum) and Focus Appearance
- Multi-platform: Web, iOS, and Android accessibility mapping
Adoption & trust: 3k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are shipping UI that might block screen reader, keyboard, or switch users because roles, labels, focus order, or touch targets were never mapped to WCAG 2.2.
Who is it for?
Solo builders defining or reviewing component libraries and product screens across web and native who want WCAG 2.2 AA baked into specs and code, not a last-minute audit panic.
Skip if: Teams that only need a one-off legal PDF checklist with no code or component context, or projects where accessibility requirements are already fully signed off with no UI changes planned.
When should I use this skill?
Defining UI component specifications for Web, iOS, or Android; auditing existing code for accessibility barriers; implementing WCAG 2.2 standards; mapping design requirements to ARIA roles, traits, and hints.
What do I get? / Deliverables
After the skill runs you get role-correct semantics, documented labeling and focus behavior, and a clearer picture of WCAG 2.2 gaps to fix before release.
- Component accessibility specifications with roles, labels, and focus behavior
- Audit notes on WCAG 2.2 compliance gaps
- Platform-specific trait and hint mappings
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the skill’s core work is specifying and implementing accessible UI components; audits and gap fixes still target frontend artifacts. Frontend is where semantic HTML/ARIA, keyboard focus, and platform accessibility traits are applied on Web, iOS, and Android.
Where it fits
Generate semantic button and dialog specs with correct roles, labels, and focus traps before your agent writes JSX or SwiftUI.
Audit shipped screens for missing names, incorrect roles, and focus visibility against WCAG 2.2.
Bake minimum target sizes and keyboard paths into a clickable prototype so validation feedback is accessible from day one.
How it compares
Use instead of generic “make it accessible” prompts that skip POUR, the accessibility tree, and platform-specific trait mapping.
Common Questions / FAQ
Who is accessibility for?
It is for solo and indie developers and designers shipping web or native products who want their agent to implement and audit WCAG 2.2 Level AA with concrete ARIA and platform attributes.
When should I use accessibility?
Use it in Build when specifying or coding UI components; in Ship review when auditing barriers in existing code; and before launch when you need Target Size, Focus Appearance, and labeling checked on Web, iOS, or Android.
Is accessibility safe to install?
It is a documentation-style agent skill focused on standards and code guidance; review the Security Audits panel on this Prism page before installing any skill from the catalog.
SKILL.md
READMESKILL.md - Accessibility
# Accessibility (WCAG 2.2) This skill ensures that digital interfaces are Perceivable, Operable, Understandable, and Robust (POUR) for all users, including those using screen readers, switch controls, or keyboard navigation. It focuses on the technical implementation of WCAG 2.2 success criteria. ## When to Use - Defining UI component specifications for Web, iOS, or Android. - Auditing existing code for accessibility barriers or compliance gaps. - Implementing new WCAG 2.2 standards like Target Size (Minimum) and Focus Appearance. - Mapping high-level design requirements to technical attributes (ARIA roles, traits, hints). ## Core Concepts - **POUR Principles**: The foundation of WCAG (Perceivable, Operable, Understandable, Robust). - **Semantic Mapping**: Using native elements over generic containers to provide built-in accessibility. - **Accessibility Tree**: The representation of the UI that assistive technologies actually "read." - **Focus Management**: Controlling the order and visibility of the keyboard/screen reader cursor. - **Labeling & Hints**: Providing context through `aria-label`, `accessibilityLabel`, and `contentDescription`. ## How It Works ### Step 1: Identify the Component Role Determine the functional purpose (e.g., Is this a button, a link, or a tab?). Use the most semantic native element available before resorting to custom roles. ### Step 2: Define Perceivable Attributes - Ensure text contrast meets **4.5:1** (normal) or **3:1** (large/UI). - Add text alternatives for non-text content (images, icons). - Implement responsive reflow (up to 400% zoom without loss of function). ### Step 3: Implement Operable Controls - Ensure a minimum **24x24 CSS pixel** target size (WCAG 2.2 SC 2.5.8). - Verify all interactive elements are reachable via keyboard and have a visible focus indicator (SC 2.4.11). - Provide single-pointer alternatives for dragging movements. ### Step 4: Ensure Understandable Logic - Use consistent navigation patterns. - Provide descriptive error messages and suggestions for correction (SC 3.3.3). - Implement "Redundant Entry" (SC 3.3.7) to prevent asking for the same data twice. ### Step 5: Verify Robust Compatibility - Use correct `Name, Role, Value` patterns. - Implement `aria-live` or live regions for dynamic status updates. ## Accessibility Architecture Diagram ```mermaid flowchart TD UI["UI Component"] --> Platform{Platform?} Platform -->|Web| ARIA["WAI-ARIA + HTML5"] Platform -->|iOS| SwiftUI["Accessibility Traits + Labels"] Platform -->|Android| Compose["Semantics + ContentDesc"] ARIA --> AT["Assistive Technology (Screen Readers, Switches)"] SwiftUI --> AT Compose --> AT ``` ## Cross-Platform Mapping | Feature | Web (HTML/ARIA) | iOS (SwiftUI) | Android (Compose) | | :----------------- | :----------------------- | :----------------------------------- | :---------------------------------------------------------- | | **Primary Label** | `aria-label` / `<label>` | `.accessibilityLabel()` | `contentDescription` | | **Secondary Hint** | `aria-describedby` | `.accessibilityHint()` | `Modifier.semantics { stateDescription = ... }` | | **Action Role** | `role="button"` | `.accessibilityAddTraits(.isButton)` | `Modifier.semantics { role = Role.Button }` | | **Live Updates** | `aria-live="polite"` | `.accessibilityLiveRegion(.polite)` | `Modifier.semantics { liveRegion = LiveRegionMode.Polite }` | ## Examples ### Web: Accessible Search ```html <form role="search"> <label for="search-input" class="s