Better Accessibility
Accessibility engineering for product interfaces, from focus states and keyboard...
Install
npx skills add trycompai/crm --skill better-accessibility -g -a claude-code -y- Repository
- trycompai/crm11.8k
- Category
- Design
- Updated
- 4d ago
- License
- MIT
- Context cost
- Mediumabout 2,900 tokens
- Runs scripts
- No, instructions only
What it does
Accessibility engineering for product interfaces, from focus states and keyboard support to ARIA, forms, and screen readers. Use when building or reviewing UI components, modals, menus, forms, custom widgets, or when the user says "make this accessible" or reports keyboard or screen-reader issues. Triggers on accessibility, a11y, WCAG, aria, focus ring, focus-visible, focus trap, keyboard navigation, tab order, tabindex, screen reader, sr-only, aria-live, alt text, hit area, touch target, prefers-reduced-motion, autoplay, toast duration, skip link, semantic HTML, aria-label, form errors, disabled buttons, "not keyboard accessible".
Accessibility that comes with the craft
Accessibility is not a compliance checkbox bolted on at the end; it is the floor for interface craft. Most of it 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. Apply these principles when building or reviewing UI code, and match the project's existing styling system (Tailwind vs. plain CSS vs. CSS-in-JS) when applying fixes.
When reviewing, walk the interface as a keyboard-only user first (every flow must complete without a mouse), then as a screen-reader user: does each control announce a name, a role, and its state? When unsure, prefer the platform default over a custom rebuild, and remove ARIA rather than add it.
Rendered-pair contrast measurement and color remediation are covered by the better-colors skill; visual text sizing and iOS input zoom by better-typography; spatial RTL layout by better-layout.
Quick Reference
| Category | When to Use |
|---|---|
| Focus & Keyboard | Focus rings, skip links, tabindex, focus trapping, APG keyboard patterns |
| Semantics & ARIA | Native elements first, button vs link, landmarks, accessible names, disabled states |
| Forms | Labels, autocomplete, error messaging, input types |
| Screen Readers | Visually hidden content, live regions, toasts, alt text, SVG |
| Hit Areas | Target sizes, expanding hit areas, collision rules |
| Motion & Zoom | prefers-reduced-motion, autoplay and timed UI, 200% zoom, reflow, rem vs px |
Core Principles
1. Native Elements First
The first rule of ARIA: don't use ARIA when a native element exists. <button> for actions, <a href> for navigation (it must support Cmd/Ctrl/middle-click), never <div onClick>. No ARIA is better than bad ARIA.
