better-accessibility

Reviews and fixes UI code for keyboard, ARIA, forms, and screen-reader accessibility.

Updated Jul 29, 2026
One-click install
npx skills add https://github.com/zomeru/zomlab --skill better-accessibility-zomeru
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: better-accessibility
Source: https://github.com/zomeru/zomlab/tree/main/.agents/skills/better-accessibility
Command: npx skills add https://github.com/zomeru/zomlab --skill better-accessibility-zomeru

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Interfaces often ship with invisible focus rings, unlabeled icon buttons, keyboard-inaccessible widgets, and form errors that screen readers never announce. This Skill provides concrete principles, code patterns, and a structured review format for building and auditing accessible product interfaces against WCAG requirements. ## Core Features & Use Cases - Focus and keyboard engineering: Style :focus-visible rings, implement skip links, roving tabindex, focus trapping with inert, and ARIA APG keyboard patterns for tabs, menus, dialogs, and comboboxes. - Semantics, ARIA, and screen readers: Apply native-elements-first rules, accessible names, landmarks, live regions (role="status" vs role="alert"), visually hidden content, alt text by purpose, and SVG labeling. - Forms, hit areas, and motion: Build labeled inputs with autocomplete and aria-describedby error messaging, meet WCAG 2.5.8 target sizes with pseudo-element hit-area expansion, and honor prefers-reduced-motion, 200% zoom, and 320px reflow. - Use Case: When reviewing a React modal component, the Skill checks focus trapping and restoration, Escape handling, accessible naming, and produces a severity-ranked findings table with before/after code fixes. ## Quick Start Ask the AI to review a component or page for accessibility issues, for example: "Review this checkout form for keyboard and screen-reader accessibility."

Frequently Asked Questions about better-accessibility

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I make a modal dialog keyboard accessible?▼

Use native `<dialog>` with `showModal()` for a free focus trap, inert background, and Escape handling. For custom overlays, set `inert` on background content, move focus inside on open, add `role="dialog"` and `aria-modal="true"`, and return focus to the trigger on close.

How to style focus rings without breaking accessibility?▼

Style `:focus-visible` instead of bare `:focus` so keyboard users see a ring while mouse users usually do not. Prefer the browser's default indicator or a verified project token, use at least a 2px solid perimeter, and never use `outline: none` without a replacement.

What is the difference between role=status and role=alert?▼

`role="status"` is a polite live region that waits for a pause, used for toasts, result counts, and loading updates. `role="alert"` is assertive and interrupts immediately, reserved for urgent errors not tied to a specific control.

Does WCAG require a minimum click target size?▼

WCAG 2.5.8 Level AA requires a 24×24 CSS-pixel target or one of its spacing, equivalent-control, inline, user-agent, or essential exceptions. For usability, aim for 44×44px on touch and 40×40px on desktop, extending small elements with a pseudo-element.

Why is using a div with onClick bad for accessibility?▼

A `<div onClick>` has no role, no keyboard focus, and no Enter/Space activation, so screen readers and keyboard users cannot operate it. Use `<button>` for actions and `<a href>` for navigation, which provide these behaviors natively.

When should I use aria-disabled instead of the disabled attribute?▼

Use native `disabled` when a control is genuinely unavailable; it removes focus, blocks activation, and excludes form submission. Use `aria-disabled="true"` only when keeping the control focusable is intentional, then block pointer and keyboard behavior in code and style the state explicitly.