fixing-accessibility
Skill3 starsChanged 5 months agoMITView on GitHub
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.
We split this skill into the rules it gives an agent
16 rules. 1 is common, 15 are distinctive, and 0 are very specific to this project.
1
Common
Most of the 11 edited versions we read keep these.
15
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
- Distinctive: line 21
Do not rewrite large parts of the UI.
- Distinctive: line 51
every interactive control must have an accessible name
- Distinctive: line 53
every input, select, and textarea must be labeled
- Distinctive: line 59
do not use div or span as buttons without full keyboard support
- Distinctive: line 60
all interactive elements must be reachable by Tab
- Distinctive: line 62
do not use tabindex greater than 0
- Distinctive: line 74
prefer native elements (button, a, input) over role-based hacks
- Distinctive: line 75
if a role is used, required aria attributes must be present
- Distinctive: line 77
do not skip heading levels
- Distinctive: line 97
ensure sufficient contrast for text and icons
- Distinctive: line 100
do not remove focus outlines without a visible replacement
- Distinctive: line 107
avoid autoplaying media with sound
- Distinctive: line 111
prefer minimal changes, do not refactor unrelated code
- Common: line 112
do not add aria when native semantics already solve the problem
- Distinctive: line 113
do not migrate UI libraries unless requested
- Distinctive: line 134
prefer native HTML before adding aria
“Common” is measured: kept by at least 6 in 10 of the 11 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.
Files
fixing-accessibility
Fix accessibility issues.
how to use
/fixing-accessibilityApply 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
<!-- 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
Trending
Surging: 1 new project took it in the last 4 weeks, none the 4 weeks before.thin data
Other versions17 projects use a version of this.
Word for word · 6
- ibelick/ui-skills★ 10k100% same
- master5d/claude-design-skills★ 26100% same
- ClaireAll/skills★ 2100% same
- strvcom/frontend-skills★ 2100% same
- xeroc/skills★ 1100% same
- davidanthonyn/claude-skills★ 0100% same
Edited · 6
- agentset-ai/agentset★ 2.1k98% same
- kapishdima/soundcn★ 86498% same
- sanmidable/skills★ 296% same
- HatriGt/agent-sandbox★ 097% same
- okfriansyah-moh/agentic-workflow★ 087% same
- TheHiddenDeveloper/jarvis-skills★ 092% same
Wrote their own version · 5
- kumaran-is/claude-code-onboarding★ 35same name
- jscraik/Agent-Skills★ 9same name
- jasonfesta/design-agents★ 1same name
- EstebanT1112/codex-engineering-workflow★ 0same name
- hebertzhu/agent-foundry★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use make-interfaces-feel-better, emil-design-eng and 7 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
studio-lgtmSkillmake-interfaces-feel-better
Apply design engineering best practices to polish UI components - use when reviewing or improving interfaces, animations, typography, or interaction details.
Also in 3 projects that use this
VercelSkillemil-design-eng
This skill encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions, and the invisible details that make software feel great.
Also in 4 projects that use this
xerocSkillimprove-animations
Survey a codebase's animation and motion code as a senior motion advisor, then produce a prioritized audit and self-contained implementation plans for other agents (or cheaper models) to execute. Read-only on source code — it plans improvements, it does not apply them. Use when the user asks to "improve the animations", "audit the motion", "make this app feel better", or wants a roadmap of animation fixes rather than a review of a single diff.
Also in 3 projects that use this
DatabricksSkillshadcn
Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for "shadcn init", "create an app with --preset", or "switch to --preset".
Also in 4 projects that use this
StrayDragonSkillui-ux-pro-max
UI/UX design intelligence. 50 styles, 21 palettes, 50 font pairings, 20 charts, 8 stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI/UX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient.
Also in 4 projects that use this
OpenAISkillverification-before-completion
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
Also in 3 projects that use this
In this repository5 other files it gives its agents.
- baseline-uiSkill
- fixing-metadataSkill
- fixing-motion-performanceSkill
- improve-uiSkill
- ui-skills-rootSkill
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.

