agentleFS
Sign inStart free
sanmidablesanmidable/skills/skills/ibelick/fixing-accessibility/SKILL.md

fixing-accessibility

Skill2 starsChanged 4 months agoMITView on GitHub

Fix accessibility issues. - /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. Reference these guidelines when: - adding or changing buttons, links, inputs, menus, dialogs, tabs, dropdowns - building forms, validation, error…

We split this skill into the rules it gives an agent

16 rules. 16 are common, 0 are distinctive, and 0 are very specific to this project.

  • 16

    Common

    Most of the 17 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Do not rewrite large parts of the UI.

    line 23
  2. Common:

    every interactive control must have an accessible name

    line 53
  3. Common:

    every input, select, and textarea must be labeled

    line 55
  4. Common:

    do not use div or span as buttons without full keyboard support

    line 61
  5. Common:

    all interactive elements must be reachable by Tab

    line 62
  6. Common:

    do not use tabindex greater than 0

    line 64
  7. Common:

    prefer native elements (button, a, input) over role-based hacks

    line 76
  8. Common:

    if a role is used, required aria attributes must be present

    line 77
  9. Common:

    do not skip heading levels

    line 79
  10. Common:

    ensure sufficient contrast for text and icons

    line 99
  11. Common:

    do not remove focus outlines without a visible replacement

    line 102
  12. Common:

    avoid autoplaying media with sound

    line 109
  13. Common:

    prefer minimal changes, do not refactor unrelated code

    line 113
  14. Common:

    do not add aria when native semantics already solve the problem

    line 114
  15. Common:

    do not migrate UI libraries unless requested

    line 115
  16. Common:

    prefer native HTML before adding aria

    line 136

“Common” is measured: kept by at least 6 in 10 of the 17 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

---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. author: ibelick source: https://github.com/ibelick/ui-skills homepage: https://github.com/ibelick/ui-skills/blob/main/skills/fixing-accessibility/SKILL.md

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

prioritycategoryimpact
1accessible namescritical
2keyboard accesscritical
3focus and dialogscritical
4semanticshigh
5forms and errorshigh
6announcementsmedium-high
7contrast and statesmedium
8media and motionlow-medium
9tool boundariescritical

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

<!-- 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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free