Helps your project comply with accessibility standards and best practices.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
This is a companion checklist. Core's accessibility owner is
docs/ai/skills/accessibility-review/SKILL.md, subordinate to
docs/ai/rules/frontend.md and docs/ai/rules/testing.md.
Keep Core's Base UI, base-maia style, Zinc tokens, and
docs/ai/rules/frontend.md authoritative. Reconcile this overlay after upstream refreshes
before running bun run skills:sync.
accessibility-review or skip axe/manual verification.docs/ai/skills/accessibility-review/SKILL.md first.base-maia focus/contrast patterns.accessibility-review remained the Core a11y owner.This skill reviews and fixes semantics, keyboard and focus behavior, accessible names, forms, announcements, motion and zoom. It reports each failure against the WCAG criterion it breaks and writes the fix in the project's styling system.
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, iOS input zoom and language metadata belong to better-typography. Spacing between targets and spatial RTL belong to better-layout. Label, error and alt-text wording belong to better-writing. Animation recipes, hover styling and scroll containment belong to better-ui.
A finding cites a WCAG 2.2 Level A or AA criterion by number, or a concrete task an assistive-technology user cannot complete. Everything else is a recommendation and never HIGH. That covers AAA criteria, APG conventions, the one-<h1> and no-skipped-levels outline and the 44px and 40px targets. The criterion thresholds below are exact. The larger targets are heuristics, so keep an established, usable density.
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. See semantics-and-aria.md for landmarks and button-vs-link.
Use native disabled when a control is genuinely unavailable. Reach for aria-disabled="true" only when it should stay focusable, then block pointer, keyboard and form behavior in code and style the state explicitly. The rules are in semantics-and-aria.md.
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. It must reach 3:1 against every adjacent color it crosses, currentColor included, under 1.4.11. A 2px solid perimeter with a 3:1 change of contrast is the 2.4.13 AAA target. Never use outline: none without a verified replacement, and preserve system colors in forced-colors mode.
A focused element must never sit fully hidden behind a sticky header, footer or banner (2.4.11). Give the scroller scroll-padding-top equal to the sticky header's height. Recipes are in focus-and-keyboard.md.
Every pointer interaction needs a keyboard path. Follow the ARIA APG patterns: Escape closes overlays, arrow keys move within composite widgets, Tab moves between widgets, Enter and Space activate buttons.
Use only tabindex="0" to join the natural tab order and tabindex="-1" for programmatic focus. Positive values break that order. Composite widgets use roving tabindex, where the active item is 0 and every other is -1. Where focus must stay in an input, as in a combobox, use aria-activedescendant instead. Key maps per widget are in focus-and-keyboard.md.
Prefer <dialog> opened with showModal(), which makes the background inert and handles Escape. A custom overlay sets inert on the background, role="dialog" and aria-modal="true" on itself. Either way, move focus inside on open and return it to the trigger on close.
Client-side route changes reset nothing. Update document.title and move focus to the new view's <h1> or <main>. Both recipes are in focus-and-keyboard.md.
WCAG 2.5.8's Level AA baseline is a 24×24 CSS-pixel target, or one of its exceptions. Aim for 44×44px on touch and 40×40px on desktop where density permits. Extend with a pseudo-element when the visible element should stay smaller.
Never let extended hit areas overlap. Give decorative layers pointer-events: none, so a glow never swallows the clicks meant for the control beneath it.
Every drag interaction needs a single-pointer alternative, such as buttons or a menu that reorder or move the same item (2.5.7). Sizes, exceptions and collision rules are in hit-areas.md.
Every input gets a <label for> or a wrapping <label>. A placeholder is never a label. Label and control share one hit target, with no dead zone between a checkbox and its text.
Add a valid autocomplete token and a descriptive name attribute, plus the type and inputmode that summon the right keyboard. Never block paste; users paste passwords and one-time codes. See forms.md. <!-- pragma: allowlist secret -->
Validate on submit, never by disabling submit until the form is valid. Mark failing fields aria-invalid="true", point aria-describedby at the inline error text and focus the first invalid field. Submit behavior while the request runs is in forms.md.
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: an icon, text or an underline alongside the color (1.4.1).
This skill decides which contrast requirement applies:
| Criterion | Applies to | Minimum |
|---|---|---|
| 1.4.3 AA | Text | 4.5:1 |
| 1.4.3 AA | Large text, at least 24px or 18.67px bold | 3:1 |
| 1.4.11 AA | UI component boundaries, states and meaningful graphics | 3:1 |
Inactive controls and logos are exempt. Use better-colors to measure the rendered pair. When it fails, report the pair and the criterion it misses, and leave the colors alone 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, and kill parallax and autoplay entirely. See motion-and-zoom.md.
Anything moving, blinking or updating on its own for more than 5 seconds needs a visible pause control (2.2.2). Toasts carrying an action or an error stay until dismissed. The rules are in motion-and-zoom.md.
Three mechanisms, three jobs. aria-describedby carries field-specific validation. A polite live region (role="status") carries non-urgent updates not tied to a control, such as toasts and result counts. role="alert" carries urgent untied errors and nothing else.
Repeated polite announcements need a stable empty region rendered before its text updates. Dynamically inserted alerts vary in support, so test them on the screen readers you target. See screen-readers.md.
Decorative images get alt="". Informative images describe the meaning. Functional images describe the action, never the picture. The full table is in screen-readers.md.
Use headings that describe their sections and form a coherent outline. 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.
Text must survive 200% resize (1.4.4), and the page must reflow at 320px width without horizontal scrolling (1.4.10). Text containers take min-height, not height, and better-layout owns the rest of that fix. Never set maximum-scale=1 or user-scalable=no in the viewport meta. iOS input zoom is fixed with better-typography's 16px rule instead.
| Pattern | Fix |
|---|---|
outline: none or outline-none with no focus-visible replacement nearby | Restore the browser ring or add a verified custom one |
<div onClick or <span onClick | Use <button>, or <a href> when it navigates |
role="button" or role="tab" with no onKeyDown | Use the native element, or implement the APG key map |
tabIndex={1} or any positive tabindex | Fix the DOM order and use 0 |
disabled={!isValid} on a submit button | Keep it enabled and validate on submit |
{msg && <div role="status">, region mounted with its text | Render the empty region first and update its text |
aria-live="assertive" on a success toast | role="status" |
<img with no alt attribute | alt="" if decorative, otherwise describe the purpose |
aria-label whose text omits the visible label | Start the name with the visible text |
aria-hidden on an ancestor of a button, link or input | Remove it, or make the subtree inert |
maximum-scale=1 or user-scalable=no | Remove it |
position: sticky header with no scroll-padding-top on the scroller | Pad the scroller by the header height |
Tooltip on a natively disabled control | Text beside it, or aria-disabled so it stays focusable |
onDragStart or a drag library with no button alternative | Add a single-pointer path to the same result |
Severity. HIGH prevents a task, hides content from assistive technology or creates a systemic failure. MEDIUM makes an interaction meaningfully harder. LOW is isolated polish. This domain's share of better-interface's escalation triggers is HIGH on sight. That is a missing accessible name, a missing focus indicator and a pointer path with no keyboard path. It is also motion ignoring reduced motion, loss at 320px or 200% and meaning carried by color alone.
Verification. Without a browser: accessible names on every interactive element, keyboard handlers on non-native controls, focus styles, prefers-reduced-motion guards and form labels bound to their inputs. With one: tab the flow in order, read computed names and roles from the accessibility tree, confirm a visible focus indicator at every stop and run an automated audit. Report every check you could not run as Not verified.
Format. Group findings under the principle each violates, ordered by severity, one row per root cause listing every location it appears in:
| Severity | Location | Before | After | Why |
|---|
Location is path/to/file:line. Why names the WCAG criterion or principle and the user impact.
End with Block when any HIGH remains, Approve otherwise, leaving the rest in the table as work to do. Never Approve coverage you did not inspect. With nothing to report, state "No actionable accessibility findings" and report verification.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Audit and fix accessibility in Core UI. Use when changing or reviewing buttons, links, forms, validation, dialogs, menus, tabs, tables, keyboard interactions, focus management, accessible names, announcements, contrast, touch targets, reduced motion, or WCAG/a11y behavior.
The English summary is being prepared. Showing the original description.
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.
The English summary is being prepared. Showing the original description.
Use when building any system where email content triggers actions — AI agent inboxes, automated support handlers, email-to-task pipelines, or any workflow processing untrusted inbound email. Always use this skill when the user wants to receive emails and act on them programmatically, even if they don't mention "agent" — the skill contains critical security patterns (sender allowlists, content filtering, sandboxed processing) that prevent untrusted email from controlling your system.
The English summary is being prepared. Showing the original description.
Tasteful, subtle web UI animation following Emil Kowalski / animations.dev principles. Use when adding or reviewing interface motion — hover and press feedback, entrances and exits, modals, toasts, menus, loading and skeleton states, staggered reveals, page or view transitions — so motion stays refined and purposeful, not decorative. Covers CSS, Web Animations, and React timing/easing. Pair with the motion skill for motion/react API specifics.
The English summary is being prepared. Showing the original description.
Build an animation from scratch, making the decisions in the order that determines whether it feels right — should it animate at all, what purpose, which tool, which properties, which curve and duration, how it interrupts, how it exits. Writes the implementation. Use when asked to animate something, add motion, make a component feel alive, or build a transition. For critiquing existing motion use review-animations; for auditing a whole codebase use improve-animations. Only runs when explicitly invoked; it does not trigger on its own.
The English summary is being prepared. Showing the original description.
Build animations for Expo and React Native only, using Reanimated, Gesture Handler, Expo Router, and expo-haptics. Use when the target runtime is an Expo or React Native app. Do not use it for Core Next.js web motion; use `animate` for web. Only runs when explicitly invoked; it does not trigger on its own.
The English summary is being prepared. Showing the original description.