back
loading skill details...
Accessibility engineering for product interfaces. Use when building or reviewing UI components and custom widgets, or when the user reports a keyboard or…
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.
don't have the plugin yet? install it then click "run inline in claude" again.