better-accessibility
Skill2 starsChanged 4 months agoMITView on GitHub
Most accessibility is free if you use the platform. Native elements ship with keyboard support, real labels announce themselves and a visible focus ring is one CSS rule. Write every fix in the project's styling system, and use the exact values below rather than familiar-looking substitutes. Reviewing means two walks. Keyboard-only, where every flow completes without a mouse. Then screen-reader, where every control announces a name, a role and its state. When unsure, take the platform default over a custom…
We split this skill into the rules it gives an agent
8 rules. 1 is common, 1 is distinctive, and 6 are very specific to this project.
1
Common
Most of the 18 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Write every fix in the project's styling system, and use the exact values below rather than familiar-looking substitutes.
- Common: line 30
Every pointer interaction needs a keyboard path.
- Very specific: line 32
Use only tabindex="0" to join the natural tab order and tabindex="-1" for programmatic focus.
- Very specific: line 42
Never let extended hit areas overlap.
- Very specific: line 46
Every input gets a <label for> or a wrapping <label>.
- Very specific: line 48
Add autocomplete with a meaningful name, plus the type and inputmode that summon the right keyboard.
- Very specific: line 52
Keep submit enabled until the request starts, then disable with a spinner and the original label.
- Very specific: line 54
Use native disabled when a control is genuinely unavailable.
“Common” is measured: kept by at least 6 in 10 of the 18 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
---name: better-accessibility description: Helps your project comply with accessibility standards and best practices. author: jakubkrehel source: https://github.com/jakubkrehel/skills homepage: https://github.com/jakubkrehel/skills/blob/main/skills/better-accessibility/SKILL.md
Accessibility
Most accessibility is free if you use the platform. Native elements ship with keyboard support, real labels announce themselves and a visible focus ring is one CSS rule.
Write every fix in the project's styling system, and use the exact values below rather than familiar-looking substitutes.
Reviewing means two walks. Keyboard-only, where every flow completes without a mouse. Then screen-reader, where every control announces a name, a role and its state. When unsure, take the platform default over a custom rebuild, and remove ARIA rather than add it.
Contrast measurement and color fixes belong to better-colors. Text sizing and iOS input zoom belong to better-typography. Spatial RTL layout belongs to better-layout.
Native elements first
The first rule of ARIA: don't use ARIA when a native element exists. <button> for actions, <a href> for navigation, never <div onClick>. A real link must support Cmd/Ctrl/middle-click. No ARIA is better than bad ARIA. See semantics-and-aria.md for landmarks, button-vs-link and disabled states.
Visible focus rings
Style :focus-visible, not bare :focus. Keyboard users get a ring and mouse users usually don't. Prefer the browser's unmodified indicator.
A custom ring needs a project focus token or another explicit color. Verify the whole indicator against every adjacent color it crosses, currentColor included. Use at least a 2px solid perimeter or an equivalent visible area. Never use outline: none without a verified replacement, and preserve system colors in forced-colors mode. Recipes are in focus-and-keyboard.md.
Full keyboard support
Every pointer interaction needs a keyboard path. Follow the ARIA APG patterns: Escape closes overlays, arrow keys move within composite widgets, Tab moves between widgets, Enter and Space activate.
Use only tabindex="0" to join the natural tab order and tabindex="-1" for programmatic focus. Positive values break that order. Composite widgets use roving tabindex, where the active item is 0 and every other is -1.
Trap and restore focus
Modals set inert on the background content, move focus inside on open and return focus to the trigger on close. Add overscroll-behavior: contain so background content doesn't scroll.
Minimum hit area
WCAG 2.5.8's Level AA baseline is a 24×24 CSS-pixel target, or one of its spacing, equivalent-control, inline, user-agent and essential exceptions. Aim for 44×44px on touch and 40×40px on desktop where density permits. Extend with a pseudo-element when the visible element should stay smaller.
Never let extended hit areas overlap. Give decorative layers pointer-events: none, so a glow never swallows the clicks meant for the control beneath it. Sizes and collision rules are in hit-areas.md.
Label and type every control
Every input gets a <label for> or a wrapping <label>. A placeholder is never a label. Label and control share one hit target, with no dead zone between a checkbox and its text.
Add autocomplete with a meaningful name, plus the type and inputmode that summon the right keyboard. Never block paste; users paste passwords and one-time codes. See forms.md.
Errors that announce
Keep submit enabled until the request starts, then disable with a spinner and the original label. Validate on submit. Mark failing fields aria-invalid="true", point aria-describedby at the inline error text and focus the first invalid field.
Use native disabled when a control is genuinely unavailable. Reach for aria-disabled="true" only when it should stay focusable, then block pointer, keyboard and form behavior in code and style the state explicitly.
Accessible names everywhere
Icon-only buttons need a descriptive aria-label. Visible label text must appear in the accessible name. Decorative elements get aria-hidden="true", never on a focusable element.
Don't rely on color alone
Status needs a redundant cue: an icon, text, or an underline alongside the color. Work out which WCAG contrast requirement applies, then use better-colors to measure the rendered pair. When it fails, report the pair and the requirement it misses, and leave the colors alone unless asked.
Honor prefers-reduced-motion
Wrap motion in @media (prefers-reduced-motion: no-preference) so it is opt-in. Under reduced motion, replace slides and scales with opacity crossfades, and kill parallax and autoplay entirely.
Two rules hold regardless of the preference. Autoplaying media needs a visible pause control, and toasts carrying an action or an error stay until dismissed. See motion-and-zoom.md.
Announce dynamic content
Three mechanisms, three jobs. aria-describedby carries field-specific validation. A polite live region (role="status") carries non-urgent updates not tied to a control, such as toasts and result counts. role="alert" carries urgent untied errors and nothing else.
Repeated polite announcements need a stable empty region rendered before its text updates. Dynamically inserted alerts vary in support, so test them on the screen readers you target. See screen-readers.md.
Alt text by purpose
Decorative images get alt="". Informative images describe the meaning. Functional images describe the action: a search icon button is alt="Search", not alt="magnifying glass".
Structure is navigation
Use headings that describe their sections and form a coherent outline. Give the page one <h1> and nest the levels below it without skipping. Expose one visible primary <main> landmark. When repeated navigation or chrome precedes it, make a "Skip to content" link the first focusable element. Anchored headings get scroll-margin-top.
Survive zoom and text resize
The page must work at 200% zoom and reflow at 320px width without horizontal scrolling. Use min-height rather than fixed height on text containers. Prefer rem breakpoints where they fit the codebase, and never let the viewport meta cap how far the reader can zoom.
Before you finish
| Mistake | Fix |
| Custom focus color assumed to work everywhere | Verify it against every adjacent color and in forced-colors mode |
| Repeated polite update inconsistently announced | Keep a stable empty status region and update its text |
assertive live region for a routine toast | Use polite; reserve assertive for errors |
aria-hidden="true" on a focusable element | Remove it or make the element non-focusable |
| Submit disabled until the form is valid | Keep it enabled; validate on submit and focus the first error |
| Hover treatment stuck after a tap on touch | Gate hover styling with @media (hover: hover) |
Tooltip on a natively disabled control | Text beside it, or aria-disabled so it stays focusable |
Reporting
Severity. HIGH prevents a task, hides content from assistive technology, or creates a systemic failure. MEDIUM makes an interaction meaningfully harder. LOW is isolated polish.
Verification. Without a browser: accessible names on every interactive element, keyboard handlers on non-native controls, focus styles, prefers-reduced-motion guards and form labels bound to their inputs. With one: tab the flow in order, read computed names and roles from the accessibility tree, confirm a visible focus indicator at every stop and run an automated audit. Report every check you could not run as Not verified.
Format. Group findings under the principle each violates, ordered by severity, one row per root cause listing every location it appears in:
| Severity | Location | Before | After | Why |
Location is path/to/file:line. Why names the principle and the user impact.
End with Block when any HIGH remains, Approve otherwise, leaving the rest in the table as work to do. Never Approve coverage you did not inspect. With nothing to report, state "No actionable accessibility findings" and report verification.
Other versions22 projects use a version of this.
Word for word · 0
None found.
Edited · 21
- trycompai/crm★ 11k29% same
- jakubkrehel/skills★ 9.7k47% same
- talebook/talebook★ 5.8k37% same
- compozy/compozy★ 2.8k100% same
- moumen-soliman/uitripled★ 1.4k95% same
- Atharvsinh-codez/ObsidianUI★ 52638% same
- boraoztunc/skills★ 33738% same
- Dimon94/dverity★ 107100% same
- Dimon94/skills★ 107100% same
- julianromli/faiz-skills★ 1629% same
11 more not listed
Wrote their own version · 1
- hsynozdamar-byte/claude-skills-edited★ 4same 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.
In this repository56 other files it gives its agents.
- AGENTS.mdAGENTS.md
- animate-expoSkill
- animateSkill
- animation-vocabularySkill
- apple-designSkill
- ask-sonnerSkill
- emil-design-engSkill
- find-animation-opportunitiesSkill
- improve-animationsSkill
- mobile-nativeSkill
- pick-ui-librarySkill
- prototypeSkill
- review-animationsSkill
- write-swiftSkill
- baseline-uiSkill
- create-design-mdSkill
- fixing-accessibilitySkill
- fixing-metadataSkill
- fixing-motion-performanceSkill
- improve-uiSkill
- ui-skills-rootSkill
- vocabularySkill
- transitions-devSkill
- transitions-polishSkill
- better-colorsSkill
- better-interfaceSkill
- better-layoutSkill
- better-typographySkill
- better-uiSkill
- better-writingSkill
- breakSkill
- explain-interfaceSkill
- interface-reviewSkill
- make-interfaces-feel-betterSkill
- variantSkill
- grill-meSkill
- grill-with-docsSkill
- improve-codebase-architectureSkill
- setup-matt-pocock-skillsSkill
- tddSkill
- triageSkill
- animateSkill
- critiqueSkill
- impeccableSkill
- polishSkill
- 12-principles-of-animationSkill
- generating-sounds-with-aiSkill
- mastering-animate-presenceSkill
- morphing-iconsSkill
- pseudo-elementsSkill
- sounds-on-the-webSkill
- to-spring-or-not-to-springSkill
- react-doctorSkill
- ux-heuristicsSkill
- ux-principlesSkill
- good-cssSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

