fixing-accessibility

Audit and fix HTML accessibility issues including ARIA labels, keyboard navigation, and focus management.

3|Updated Apr 20, 2026
One-click install
npx skills add https://github.com/langgenius/due-date-hq-jwl --skill fixing-accessibility-langgenius
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fixing-accessibility
Source: https://github.com/langgenius/due-date-hq-jwl/tree/main/.claude/skills/fixing-accessibility
Command: npx skills add https://github.com/langgenius/due-date-hq-jwl --skill fixing-accessibility-langgenius

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Interactive UI code often ships with accessibility defects—unlabeled icon buttons, keyboard-inaccessible controls, broken focus handling in dialogs, and form errors that screen readers cannot announce. This Skill audits HTML against prioritized WCAG-aligned rules and produces minimal, targeted fixes instead of large rewrites. ## Core Features & Use Cases - Prioritized rule audit: Reviews code against nine ranked categories covering accessible names, keyboard access, focus and dialogs, semantics, forms and errors, announcements, contrast, media, and tool boundaries. - Violation reporting: Quotes the exact offending snippet, explains why it fails, and proposes a concrete code-level fix. - Minimal-fix philosophy: Prefers native HTML elements over ARIA hacks and avoids refactoring unrelated code. - Use Case: While building a modal dialog with a form, run the audit to catch missing focus trapping, unlinked error messages, and an icon-only close button before shipping. ## Quick Start Ask the assistant to review your HTML or component file for accessibility violations using the fixing-accessibility rules and report each issue with a concrete fix.

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 HTML forms?

Link error messages to fields with aria-describedby, set aria-invalid on invalid inputs, and ensure every input has a label. Required fields must be announced, and disabled submit buttons should explain why they are disabled.

How do I make icon-only buttons accessible?

Add an aria-label or aria-labelledby attribute to the button so screen readers announce its purpose, and mark the inner SVG as aria-hidden="true". Every interactive control must have an accessible name.

Should I use ARIA roles or native HTML elements?

Prefer native elements like button, a, and input over role-based hacks. Only add ARIA when native semantics cannot solve the problem, and if a role is used, all required ARIA attributes must be present.

How do I handle focus in modal dialogs?

Modals must trap focus while open, set initial focus inside the dialog on open, and restore focus to the trigger element on close. Escape should close the dialog, and opening it should not scroll the page unexpectedly.

What are the limitations of automated accessibility fixes?

This approach favors minimal, targeted fixes and does not rewrite large UI sections or migrate component libraries. Complex widgets like comboboxes should use established accessible primitives rather than custom behavior.