ui-accessibility

Audits web UI against WCAG 2.2 for keyboard, ARIA, contrast, motion, and form accessibility.

15|3|Updated Jul 9, 2026
One-click install
npx skills add https://github.com/kiurakku/cursor-kit-for-ai --skill ui-accessibility-kiurakku
Or copy as Structured Prompt for Agentβ–Ό
Please help me install this Agent Skill.
Skill: ui-accessibility
Source: https://github.com/kiurakku/cursor-kit-for-ai/tree/main/plugins/frontend/skills/ui-accessibility
Command: npx skills add https://github.com/kiurakku/cursor-kit-for-ai --skill ui-accessibility-kiurakku

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Web interfaces frequently ship with accessibility failures β€” keyboard traps, missing labels, low contrast, ARIA misuse β€” that block users relying on assistive technology. This Skill provides a structured WCAG 2.2 audit workflow that catches these issues systematically instead of relying on ad-hoc manual checks. ## Core Features & Use Cases - Phased Audit Workflow: Runs automated checks (axe-core CLI, ripgrep pattern scans) first, then guides manual keyboard walkthroughs, ARIA review, contrast verification, reduced-motion checks, and form association audits. - Severity-Mapped Reporting: Classifies findings as Blocker, Major, Minor, or Pass with WCAG criterion numbers, file:line references, and concrete fixes in a ready-to-use report template. - Use Case: Before launching a checkout flow, run the audit to verify focus trapping in modals, label associations on payment form fields, and 4.5:1 text contrast β€” then hand developers a prioritized fix list mapped to WCAG success criteria. ## Quick Start Audit the login page and checkout components for WCAG 2.2 AA compliance and report all keyboard, ARIA, and contrast issues with fixes.

Frequently Asked Questions about ui-accessibility

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit a web page for WCAG accessibility compliance?β–Ό

Run automated checks first with axe-core CLI and ripgrep scans for missing alt text, unlabeled inputs, and positive tabindex. Then perform a manual keyboard walkthrough testing tab order, focus visibility, modal focus traps, and Escape behavior, mapping each finding to a WCAG criterion.

How to test keyboard navigation and focus management in web apps?β–Ό

Tab through every interactive element verifying logical order, Shift+Tab reversal, Enter/Space activation, and Escape closing modals. Focus must move into modals on open, return to the trigger on close, and move to the first invalid field on form errors.

What are common ARIA mistakes that break screen readers?β–Ό

Common failures include aria-label on non-interactive elements, role="button" without keyboard handlers, aria-hidden on focusable children, and aria-labelledby pointing to nonexistent ids. Prefer native HTML elements like <button> and <nav> over ARIA whenever possible.

What color contrast ratio is required for WCAG AA compliance?β–Ό

WCAG AA requires 4.5:1 for normal text, 3:1 for large text (18px+ or 14px+ bold), and 3:1 for UI components and focus indicators. Verify ratios with browser DevTools accessibility pane or the WebAIM Contrast Checker.

Can automated tools catch all accessibility issues?β–Ό

No β€” automated tools like axe catch roughly 30-40% of issues. Keyboard navigation, focus management, and screen reader behavior require manual testing, and some findings need verification with NVDA or VoiceOver.

How do I handle prefers-reduced-motion for accessibility?β–Ό

Wrap animations and transitions in a prefers-reduced-motion media query that reduces durations to near zero. JavaScript animation libraries should check matchMedia('(prefers-reduced-motion: reduce)'), and auto-playing carousels need pause controls.