fixing-accessibility

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

Updated Dec 9, 2025
One-click install
npx skills add https://github.com/Aki2022/skills --skill fixing-accessibility-aki2022
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fixing-accessibility
Source: https://github.com/Aki2022/skills/tree/main/fixing-accessibility
Command: npx skills add https://github.com/Aki2022/skills --skill fixing-accessibility-aki2022

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. 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, from accessible names and keyboard access (critical) to media and motion (low-medium). - Violation Reporting: Quotes the exact offending snippet, explains why it matters, and suggests a minimal fix without rewriting large parts of the UI. - Use Case: When adding a modal dialog or icon-only button, run a review to verify focus trapping, aria-labels, and keyboard support before shipping. ## Quick Start Ask the assistant to review a specific UI file against the 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 fix accessibility issues in my UI code?

Run a review of the file against the accessibility rule set, which reports each violation with the exact snippet, why it matters, and a concrete code-level fix. Critical issues like accessible names, keyboard access, and focus management are fixed first.

How to make icon-only buttons accessible?

Icon-only buttons must have an accessible name via aria-label or aria-labelledby so screen readers can announce their purpose. Decorative icons inside labeled controls should be marked aria-hidden.

What accessibility issues should I check in modals and dialogs?

Dialogs must trap focus while open, set initial focus inside, restore focus to the trigger on close, and close on Escape. Opening a dialog should also not scroll the page unexpectedly.

Should I use aria attributes or native HTML elements?

Prefer native elements like button, a, and input over role-based hacks, since they provide built-in semantics and keyboard behavior. Only add aria when native semantics cannot solve the problem, and include all required attributes for any role used.

When should I not use this accessibility review approach?

It is not suited for large-scale UI rewrites or migrating component libraries, since it enforces minimal targeted fixes. For complex widgets like comboboxes, prefer established accessible primitives over custom behavior.