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 ...
@jakubkrehel
Community-bidragyder
jakubkrehel/skills
Open source repository
Nedenstående er skillens egen dokumentation, hentet fra kildekoderepoet. Ophavsret tilhører forfatteren.
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 write every fix in the project's own idiom: the styling system already in use, never a second one alongside it.
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.
| 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 |
| Review Output Format | Severity scale, findings table, verification, verdict |
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.
Style :focus-visible, not bare :focus, so keyboard users get a ring and mouse users usually don't. Prefer the browser's unmodified focus indicator. If the design needs a custom ring, use a project focus token or another explicit color and verify the complete indicator against every adjacent color it crosses; currentColor is acceptable only after the same check. 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.
Every pointer interaction needs a keyboard path, following the ARIA APG patterns: Escape closes overlays, arrow keys move within composite widgets (tabs, menus, listboxes), Tab moves between widgets, Enter and Space activate. Only tabindex="0" (join the natural tab order) and tabindex="-1" (programmatic focus), never positive values, which break the natural order. Composite widgets use roving tabindex: the active item is 0, all others -1.
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.
WCAG 2.5.8's Level AA baseline is a 24×24 CSS-pixel target or one of its defined spacing, equivalent-control, inline, user-agent, or essential exceptions. For easier activation, aim for 44×44px in touch contexts and 40×40px in desktop interfaces when density permits. Extend with a pseudo-element if the visible element should stay smaller. Never let extended hit areas overlap, and give decorative layers pointer-events: none so a glow or gradient never swallows the clicks meant for the control beneath it.
Every input gets a <label for> or wrapping <label>; a placeholder is never a label, and label and control share one hit target: no dead zones between a checkbox and its text. Add autocomplete with a meaningful name, and the correct type and inputmode for the keyboard. Never block paste; users paste passwords and one-time codes.
Keep submit enabled until the request starts, then disable with a spinner while keeping the original label. Validate on submit: mark failing fields with aria-invalid="true", point aria-describedby at the inline error text, and focus the first invalid field. Use native disabled when a native control is genuinely unavailable. Use aria-disabled="true" only when retaining focusability or discoverability is intentional; then block pointer, keyboard, and form behavior in code and style the state explicitly.
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.
Status needs a redundant cue: icon, text, or underline alongside the color. Determine which WCAG contrast requirement applies from the content and state, then use better-colors to measure the rendered foreground/background pair. When contrast fails, report the pair and requirement it misses; do not change the project's colors unless asked.
Wrap motion in @media (prefers-reduced-motion: no-preference) so it is opt-in. Under reduced motion, replace slides and scales with opacity crossfades; kill parallax and autoplay entirely. Independent of the preference: autoplaying media needs a visible pause control, and toasts carrying actions or errors stay until dismissed.
Use aria-describedby for field-specific validation, a polite live region (role="status") for non-urgent updates not tied to a control such as toasts or result counts, and role="alert" only for urgent errors not tied to a control. For reliable repeated polite announcements, render a stable empty region before updating its text; dynamically inserted alerts have different support and must be tested with the target screen readers.
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".
Use headings that describe their sections and form a coherent outline; one page-level <h1> and properly nested levels are the recommended default, not standalone WCAG pass/fail rules. 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.
The page must work at 200% zoom and reflow at 320px width without horizontal scrolling. Use min-height instead of fixed height on text containers, prefer rem breakpoints where they fit the codebase's conventions, and keep the viewport meta from capping how far the reader can zoom.
| Mistake | Fix |
|---|---|
outline: none to remove the focus ring |
Style :focus-visible instead; mouse clicks won't show it |
| Custom focus color assumed to work everywhere | Verify the full indicator against every adjacent color and in forced-colors mode |
<div onClick> for a button or link |
<button> for actions, <a href> for navigation |
| Placeholder used as the only label | Add a visible <label for>; placeholders disappear on input |
Positive tabindex to fix focus order |
Fix the DOM order; only use 0 and -1 |
| Repeated polite update inconsistently announced | Keep a stable empty status region and update its text; test the target screen readers |
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 |
| Functional icon alt describes the picture | Describe the action: alt="Search", not alt="magnifying glass" |
| Submit disabled until the form is valid | Keep it enabled; validate on submit and focus the first error |
| Decorative glow or gradient swallowing clicks | pointer-events: none on the layer, plus aria-hidden="true" |
| Hover treatment stuck after a tap on touch | Gate hover styling with @media (hover: hover) |
Tooltip on a natively disabled control |
Persistent text beside it, or aria-disabled so it stays focusable |
A standalone accessibility review is finished when every confirmed finding is reported in the format in review-output.md, with verification and a verdict. Under better-interface, its format governs instead.