fixing-accessibility

Review UI code against accessibility rules and propose minimal targeted fixes.

4|Updated Sep 30, 2024
One-click install
npx skills add https://github.com/okm321/dotfiles --skill fixing-accessibility-okm321
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: fixing-accessibility
Source: https://github.com/okm321/dotfiles/tree/main/claude/skills/fixing-accessibility
Command: npx skills add https://github.com/okm321/dotfiles --skill fixing-accessibility-okm321

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? UI code often ships with accessibility violations such as missing accessible names, broken keyboard navigation, and untrapped dialog focus, which block users who rely on assistive technologies. This Skill reviews files against a prioritized rule set and reports violations with concrete code-level fixes. ## Core Features & Use Cases - Prioritized Rule Categories: Nine categories ranked by impact, covering accessible names, keyboard access, focus and dialogs, semantics, forms and errors, announcements, contrast, media, and tool boundaries. - Violation Reports with Fixes: Quotes the exact offending snippet, explains why it matters, and suggests a minimal code-level fix without rewriting large parts of the UI. - Use Case: When adding a modal dialog or icon-only button, run the review to catch missing aria-labels, focus trapping issues, or keyboard traps before shipping. ## Quick Start Ask the assistant to review a specific UI file for accessibility issues using the fixing-accessibility rules and report violations with fixes.

Frequently Asked Questions about fixing-accessibility

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

FAQPage Schema
How do I check a file for accessibility issues?▼

Run the fixing-accessibility review on the target file to get a report of violations. Each finding quotes the exact snippet, explains why it matters in one sentence, and proposes a concrete code-level fix.

How do I make icon-only buttons accessible?▼

Icon-only buttons must have an accessible name via aria-label or aria-labelledby, and decorative icons inside them should be aria-hidden. The review flags any icon-only control missing an accessible name as a critical violation.

What accessibility issues does this check prioritize?▼

Critical issues come first: accessible names, keyboard access, focus and dialog behavior, and tool boundaries. High-priority items include semantics and form errors, followed by announcements, contrast, and media or motion concerns.

Should I add ARIA attributes to fix accessibility problems?▼

Prefer native HTML elements like button, a, and input before adding ARIA. The rules explicitly warn against adding aria when native semantics already solve the problem and against role-based hacks on div or span elements.

Will the review rewrite large parts of my UI?▼

No. The skill prefers minimal, targeted fixes and does not refactor unrelated code or migrate UI libraries unless requested. Complex widgets should use established accessible primitives rather than custom behavior.