better-accessibility

Reviews and fixes web UI code for WCAG accessibility compliance across keyboard, focus, forms, and screen readers.

Updated Jun 28, 2026
One-click install
npx skills add https://github.com/AO-HyS/aohys.com --skill better-accessibility-ao-hys
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: better-accessibility
Source: https://github.com/AO-HyS/aohys.com/tree/main/.agents/skills/better-accessibility
Command: npx skills add https://github.com/AO-HyS/aohys.com --skill better-accessibility-ao-hys

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Web interfaces frequently ship with accessibility defects: missing focus indicators, unlabeled form controls, broken keyboard navigation, and ARIA misuse that breaks screen readers. This Skill audits frontend code against WCAG standards and produces concrete, project-consistent fixes. ## Core Features & Use Cases - Keyboard and focus auditing: Verifies focus-visible rings, focus trapping in modals, roving tabindex, skip links, and full ARIA APG keyboard patterns for composite widgets. - Forms and screen reader support: Checks label associations, autocomplete tokens, error announcement via aria-describedby and live regions, accessible names, and alt text by image purpose. - Structured severity reporting: Groups findings by violated principle with HIGH/MEDIUM/LOW severity, file:line locations, before/after fixes, and a Block/Approve verdict. - Use Case: Before shipping a new React dashboard, run a review to catch a <div onClick> navigation element, a modal that leaks focus to the background, and a submit button disabled until valid, then receive exact fixes using the project's styling system. ## Quick Start Review the accessibility of the checkout form component and report any WCAG violations with fixes.

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 accessible?▼

Use native `<dialog>` with `showModal()` for free focus trapping, inert background, and Escape handling. Otherwise add `role="dialog"`, `aria-modal="true"`, set `inert` on background content, focus the first element on open, and return focus to the trigger on close.

How do I fix missing focus indicators in CSS?▼

Style `:focus-visible` rather than bare `:focus`, and never use `outline: none` without a verified replacement. Prefer the browser's default ring with added `outline-offset`, or a custom 2px outline verified against every adjacent color it crosses.

What is the minimum touch target size for WCAG?▼

WCAG 2.5.8 Level AA requires a 24×24 CSS-pixel target or one of its spacing, inline, or equivalent-control exceptions. Aim for 44×44px on touch, and extend small visible elements with a pseudo-element on the wrapping label or button.

When should I use aria-label versus visible text?▼

Prefer visible text or `aria-labelledby` over `aria-label`, which is invisible and drifts out of sync with the UI. Icon-only buttons always need an explicit `aria-label`, and visible label text must appear in the accessible name per WCAG 2.5.3.

Why should submit buttons stay enabled until the request starts?▼

Disabling submit until the form is valid prevents validation errors from ever surfacing to users. Keep it enabled, validate on submit, mark failing fields with `aria-invalid` and `aria-describedby`, and focus the first invalid field.

Does this Skill handle color contrast fixes?▼

No. Contrast measurement and color fixes belong to the separate `better-colors` skill, text sizing to `better-typography`, and RTL layout to `better-layout`. This Skill identifies which contrast requirement applies but leaves color changes alone unless asked.