Ensure WCAG 2.2 Accessibility
Your AI designs and audits interfaces that meet WCAG 2.2 Level AA standards for accessibility. It generates semantic ARIA roles and accessibility traits for Web, iOS, and Android, handling keyboard, contrast, and screen-reader support.
affaan-m on GitHub
Curated by PromptsEdge from a public repo · MIT license. All credit goes to the author.
What is this skill?
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, andcontentDescription.
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, Valuepatterns. - Implement
aria-liveor live regions for dynamic status updates.
Accessibility Architecture Diagram
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
<form role="search">
<label for="search-input" class="sr-only">Search products</label>
<input type="search" id="search-input" placeholder="Search..." />
<button type="submit" aria-label="Submit Search">
<svg aria-hidden="true">...</svg>
</button>
</form>
iOS: Accessible Action Button
Button(action: deleteItem) {
Image(systemName: "trash")
}
.accessibilityLabel("Delete item")
.accessibilityHint("Permanently removes this item from your list")
.accessibilityAddTraits(.isButton)
Android: Accessible Toggle
Switch(
checked = isEnabled,
onCheckedChange = { onToggle() },
modifier = Modifier.semantics {
contentDescription = "Enable notifications"
}
)
Anti-Patterns to Avoid
- Div-Buttons: Using a
<div>or<span>for a click event without adding a role and keyboard support. - Color-Only Meaning: Indicating an error or status only with a color change (e.g., turning a border red).
- Uncontained Modal Focus: Modals that don't trap focus, allowing keyboard users to navigate background content while the modal is open. Focus must be contained and escapable via the
Escapekey or an explicit close button (WCAG SC 2.1.2). - Redundant Alt Text: Using "Image of..." or "Picture of..." in alt text (screen readers already announce the role "Image").
Best Practices Checklist
- Interactive elements meet the 24x24px (Web) or 44x44pt (Native) target size.
- Focus indicators are clearly visible and high-contrast.
- Modals contain focus while open, and release it cleanly on close (
Escapekey or close button). - Dropdowns and menus restore focus to the trigger element on close.
- Forms provide text-based error suggestions.
- All icon-only buttons have a descriptive text label.
- Content reflows properly when text is scaled.
References
- WCAG 2.2 Guidelines
- WAI-ARIA Authoring Practices
- iOS Accessibility Programming Guide
- iOS Human Interface Guidelines - Accessibility
- Android Accessibility Developer Guide
Related Skills
frontend-patternsdesign-systemliquid-glass-designswiftui-patterns
Install this skill
- 1
Get the skill — it’s free
Use the Get this skill panel. Unlocked skills stay in My skills. - 2
Download or clone the files
Download the zip, or clone the repo and copy theskills/accessibilityfolder. - 3
Put it where your agent looks for skills
For Claude Code, use your personal skills folder (every project) or a project’s own folder:~/.claude/skills/accessibility/SKILL.md # all projects .claude/skills/accessibility/SKILL.md # this project only
- 4
Just ask
No command needed. The agent reads the skill’s description and loads it on its own when your request matches.
SKILL.md frontmatter
What your agent reads to decide when to load this skill.
--- name: accessibility description: Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA. Use when building or auditing UI that must meet WCAG 2.2 Level AA, or when reviewing a change for keyboard, contrast, or screen-reader support. standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android). ---
Files
Open any Markdown file to read it here.
Related skills
View all →- iOS 26 Liquid Glass DesignFreeBuild iOS 26 apps with dynamic Liquid Glass effects using SwiftUI, UIKit, and WidgetKit. It covers blur, reflection, interactive morphing, glass buttons, and customizable shapes and tints for modern UI components.
- Video Ingest, Index, and EditFreeYour AI ingests video or live streams, indexes visual and spoken content, and edits timelines with subtitles, overlays, and audio. It supports local files, URLs, RTSP feeds, desktop capture, and real-time alerts.
- Convert UI to Vue 3FreeTurn batches of UI screenshots or design exports into Vue 3 components. It organizes pages and modules, maps elements to Vant, Element Plus, or Ant Design Vue, and wires up routing automatically.
- Record UI Demo VideosFreeYour AI records polished web app demo videos with visible cursor and natural pacing. It explores pages first, scripts interactions, rehearses, then captures WebM videos suitable for walkthroughs or tutorials.