fixing-accessibility — Claude Code skill
This skill audits HTML accessibility and suggests focused fixes. Use it when building forms, dialogs, interactive controls, or checking WCAG issues.
npx skills add ibelick/ui-skills --skill fixing-accessibility -a claude-codeWhat fixing-accessibility does
fixing-accessibility checks accessible names, keyboard access, focus handling, dialogs, semantics, forms, errors, announcements, contrast, media, and motion. It covers issues such as missing aria-label, incorrect aria-describedby, missing aria-invalid, and incomplete expandable controls.
Run /fixing-accessibility to apply the rules to UI work in the current conversation. With /fixing-accessibility <file>, the skill reviews one file and reports the violation, why it matters, and a code-level fix. The guidance favours small, targeted changes instead of large UI rewrites.
The skill recommends native HTML elements before role-based workarounds and established accessible primitives for complex widgets. A modal must keep focus inside while open and return focus to its trigger on close; otherwise keyboard behaviour breaks.
What it helps with
- audit accessible names for controls and fields
- check keyboard access across interactive elements
- link form errors to their fields
- review focus handling in dialogs
- find contrast and state issues
Example prompts for the agent
- Apply the accessibility rules to this interface:
/fixing-accessibility - Review
src/components/Dialog.htmlagainst every rule:/fixing-accessibility <file> - Check this form and suggest targeted accessibility fixes:
/fixing-accessibility
How to install fixing-accessibility
1Skills CLI (Vercel)
npx skills add ibelick/ui-skills --skill fixing-accessibility -a claude-code2Manually: put the files in place
~/.claude/skills/fixing-accessibility/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/fixing-accessibility/
1Skills CLI (Vercel)
npx skills add ibelick/ui-skills --skill fixing-accessibility -a codex2Manually: put the files in place
.agents/skills/fixing-accessibility/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add ibelick/ui-skills --skill fixing-accessibility -a cursor2Manually: put the files in place
.cursor/skills/fixing-accessibility/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install ibelick/ui-skills fixing-accessibility2Manually: put the files in place
.github/skills/fixing-accessibility/SKILL.md1Skills CLI (Vercel)
npx skills add ibelick/ui-skills --skill fixing-accessibility -a gemini-cli2Platform CLI
gemini skills install https://github.com/ibelick/ui-skills --path skills/fixing-accessibilityManually: put the files in place
.devin/skills/fixing-accessibility/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add ibelick/ui-skills --skill fixing-accessibility -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about fixing-accessibility
How do I install fixing-accessibility in Claude Code?
Run npx skills add ibelick/ui-skills --skill fixing-accessibility -a claude-code. The skill file will be available at ~/.claude/skills/fixing-accessibility/SKILL.md.
What does fixing-accessibility do?
It reviews HTML and UI work for issues with ARIA, keyboard access, focus, dialogs, forms, contrast, and states. For a specific file, it reports the violation, its impact, and a code-level fix.
Which platforms support fixing-accessibility?
The skill supports Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, and OpenCode.
Source text
SKILL.md · MIT
--- name: fixing-accessibility description: Audit and fix HTML accessibility issues including ARIA labels, keyboard navigation, focus management, color contrast, and form errors. Use when adding interactive controls, forms, dialogs, or reviewing WCAG compliance. --- # fixing-accessibility Fix accessibility issues. ## how to use - `/fixing-accessibility` Apply these constraints to any UI work in this conversation. - `/fixing-accessibility <file>` Review the file against all rules below and report: - violations (quote the exact line or snippet) - why it matters (one short sentence) - a concrete fix (code-level suggestion) Do not rewrite large parts of the UI. Prefer minimal, targeted fixes. ## when to apply Reference these guidelines when: - adding or changing buttons, links, inputs, menus, dialogs, tabs, dropdowns - building forms, validation, error states, helper text - implementing keyboard shortcuts or custom interactions - working on focus states, focus trapping, or modal behavior - rendering icon-only controls - adding hover-only interactions or hidden content ## rule categories by priority | priority | category | impact | |----------|----------|--------| | 1 | accessible names | critical | | 2 | keyboard access | critical | | 3 | focus and dialogs | critical | | 4 | semantics | high | | 5 | forms and errors | high | | 6 | announcements | medium-high | | 7 | contrast and states | medium | | 8 | media and motion | low-medium | | 9 | tool boundaries | critical | ## quick reference ### 1. accessible names (critical) - every interactive control must have an accessible name - icon-only buttons must have aria-label or aria-labelledby - every input, select, and textarea must be labeled - links must have meaningful text (no “click here”) - decorative icons must be aria-hidden ### 2. keyboard access (critical) - do not use div or span as buttons without full keyboard support - all interactive elements must be reachable by Tab - focus must be visible for keyboard users - do not use tabindex greater than 0 - Escape must close dialogs or overlays when applicable ### 3. focus and dialogs (critical) - modals must trap focus while open - restore focus to the trigger on close - set initial focus inside dialogs - opening a dialog should not scroll the page unexpectedly ### 4. semantics (high) - prefer native elements (button, a, input) over role-based hacks - if a role is used, required aria attributes must be present - lists must use ul or ol with li - do not skip heading levels - tables must use th for headers when applicable ### 5. forms and errors (high) - errors must be linked to fields using aria-describedby - required fields must be announced - invalid fields must set aria-invalid - helper text must be associated with inputs - disabled submit actions must explain why ### 6. announcements (medium-high) - critical form errors should use aria-live - loading states should use aria-busy or status text - toasts must not be the only way to convey critical information - expandable controls must use aria-expanded and aria-controls ### 7. contrast and states (medium) - ensure sufficient contrast for text and icons - hover-only interactions must have keyboard equivalents - disabled states must not rely on color alone - do not remove focus outlines without a visible replacement ### 8. media and motion (low-medium) - images must have correct alt text (meaningful or empty) - videos with speech should provide captions when relevant - respect prefers-reduced-motion for non-essential motion - avoid autoplaying media with sound ### 9. tool boundaries (critical) - prefer minimal changes, do not refactor unrelated code - do not add aria when native semantics already solve the problem - do not migrate UI libraries unless requested ## common fixes ```html <!-- icon-only button: add aria-label --> <!-- before --> <button><svg>...</svg></button> <!-- after --> <button aria-label="Close"><svg aria-hidden="true">...</svg></button> <!-- div as button: use native element --> <!-- before --> <div onclick="save()">Save</div> <!-- after --> <button onclick="save()">Save</button> <!-- form error: link with aria-describedby --> <!-- before --> <input id="email" /> <span>Invalid email</span> <!-- after --> <input id="email" aria-describedby="email-err" aria-invalid="true" /> <span id="email-err">Invalid email</span> ``` ## review guidance - fix critical issues first (names, keyboard, focus, tool boundaries) - prefer native HTML before adding aria - quote the exact snippet, state the failure, propose a small fix - for complex widgets (menu, dialog, combobox), prefer established accessible primitives over custom behavior
© ibelick · MIT · ibelick/ui-skills