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/thefear078/cursor-kit-for-ai --skill ui-accessibility-thefear078
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ui-accessibility
Source: https://github.com/thefear078/cursor-kit-for-ai/tree/main/plugins/frontend/skills/ui-accessibility
Command: npx skills add https://github.com/thefear078/cursor-kit-for-ai --skill ui-accessibility-thefear078

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Web interfaces often 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 before launch and maps every finding to a specific WCAG criterion with a concrete fix. ## Core Features & Use Cases - Automated checks first: Runs axe-core CLI and ripgrep patterns to detect missing alt text, unlabeled inputs, positive tabindex, and aria-hidden focusable elements. - Manual keyboard and screen reader protocol: Tests tab order, focus traps in modals, focus-visible indicators, and accessible names against WCAG 2.1.1, 2.4.3, and 4.1.2. - Severity-ranked report: Classifies findings as Blocker, Major, Minor, or Pass with file:line references, WCAG success criterion numbers, and fixes. - Use Case: Before releasing a checkout flow, run the audit to verify keyboard operability, form label associations, error announcements via aria-describedby, and 4.5:1 text contrast, then hand developers a prioritized fix list. ## Quick Start Audit the login page and checkout components for WCAG 2.2 AA compliance and report all blockers 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 website for WCAG accessibility compliance?▼

Start with automated checks using axe-core CLI and ripgrep patterns for missing alt text, unlabeled inputs, and positive tabindex. Then perform a manual keyboard walkthrough testing tab order, focus traps, and Escape behavior, and report findings mapped to WCAG criterion numbers.

How to test keyboard navigation in web applications?▼

Tab through every page verifying all interactive elements are reachable, tab order follows visual order, Enter and Space activate controls, and Escape closes modals. Confirm no keyboard traps exist and a skip link appears as the first tab stop.

What color contrast ratio is required for WCAG AA?▼

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

Can automated tools like axe catch all accessibility issues?▼

No, automated tools like axe catch roughly 30-40% of accessibility issues. Manual keyboard testing, focus management verification in modals, and screen reader checks with NVDA or VoiceOver are required for full WCAG conformance.

When should I use ARIA attributes versus native HTML?▼

Use native HTML elements like button, nav, and input whenever they solve the need, since the first rule of ARIA is to avoid it when native HTML works. Reserve ARIA for patterns native elements cannot express, such as aria-expanded, aria-live regions, and icon button labels.