Skip to main content
skill CX Codex

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.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add ibelick/ui-skills --skill fixing-accessibility -a claude-code
Open on GitHub

What 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.html against 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-code

2Manually: put the files in place

~/.claude/skills/fixing-accessibility/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/fixing-accessibility/

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

Similar skills

Everything for Frontend and UI →

From the same set9

The whole set →

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor