メニュー
Builds UI that everyone can use — keyboard, screen reader, low vision, reduced motion, and motor differences. Use when creating or changing any user-facing interface, implementing custom widgets, fixing a11y bugs, or preparing for an audit.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Meta-skill that routes a task to the right engineering skill. Load this at the start of a session or when unsure which skill applies — it maps intent to the process that should govern the work.
Catches breaking changes between services before they ship, by testing the contract each consumer actually depends on instead of spinning up the whole system. Use when services deploy independently, when a provider API change could break a consumer, or when end-to-end integration tests are too slow and flaky to guard every service boundary.
Proves whether a change actually moves the metric, with a valid A/B test instead of a guess — a hypothesis, a primary metric, a pre-computed sample size, guardrail metrics, and an honest readout. Use when shipping a change meant to improve a number (conversion, retention, performance), running an A/B or holdout, or deciding whether a feature "worked."
Decouples deploy from release using feature flags — ship code dark, roll out gradually, kill instantly, and remove the flag once it's done. Use when releasing risky or large changes, rolling out by percentage/cohort, delivering A/B variants, or when stale flags are accumulating as debt.
Finds security risks at design time — before code exists — by mapping the system, enumerating how it could be attacked, and deciding what to do about each threat. Use when designing a feature that touches auth, data, money, or external input, when changing a trust boundary, or when a security-sensitive change needs a structured risk pass rather than a code-level review.
Designs durable, curated memory that an agent carries across sessions — what to persist, how to scope and retrieve it, and how to stop it from drifting or poisoning later runs. Use when an agent needs to remember decisions, preferences, or project facts beyond one context window, or when stale/over-generalized memory is corrupting its behavior.
| name | accessibility |
| description | Builds UI that everyone can use — keyboard, screen reader, low vision, reduced motion, and motor differences. Use when creating or changing any user-facing interface, implementing custom widgets, fixing a11y bugs, or preparing for an audit. |
Accessible UI works for people using a keyboard, a screen reader, magnification, voice control, reduced motion, or touch — not just a mouse and perfect vision. Target WCAG 2.2 Level AA unless the product has a stricter bar. Accessibility is a requirement built into every change, not a polish step at the end; retrofitting costs far more and rarely catches everything.
This skill is the full process. Run the accessibility checklist alongside it for a quick pass. For visual polish and non-a11y UI states, pair with [[ui-craft]]. For proving behavior in a running app, finish with [[browser-checks]].
Skip as the primary skill for changes with no user-facing surface (pure backend, tooling). Still apply if those changes affect auth flows, emails, or PDFs users receive.
Work in order. Later steps assume earlier foundations are solid.
Structure is free accessibility — get it right before styling.
<h1> per view and a logical heading order (h1 → h2 → h3, no skipped levels).<header>, <nav>, <main>, <footer>. One <main> per page.#main.lang on <html> (and lang on inline passages in another language).ul/ol), tables (table/th/td), and forms (form, fieldset, legend)
— not styled div stacks.<a href="#"> or <div onClick> for actions.<!-- Prefer -->
<button type="button" aria-expanded="false">Menu</button>
<!-- Not -->
<div role="button" tabindex="0" onclick="...">Menu</div>
The first rule of ARIA: if a native HTML element already gives the semantics and behavior you need, use it. ARIA patches gaps; it does not fix bad markup.
Reach for ARIA when:
aria-live, role="status", role="alert").Never:
role="button" on a link).role="navigation" on <nav> is redundant).When building custom widgets, follow the WAI-ARIA Authoring Practices patterns for keyboard behavior, roles, and states — don't invent interaction models.
If you can't complete the flow with keyboard alone, it's not done.
outline: none without a replacement that meets 3:1 contrast.tabindex values.tabindex="0" puts non-focusable elements in tab order; tabindex="-1" makes something
programmatically focusable but not tabbable (error summaries, modal containers on open).Expected keys (implement or preserve natively):
| Pattern | Keys |
|---|---|
| Button, link | Enter, Space (buttons); Enter (links) |
| Modal / menu | Esc closes; focus trapped inside modal |
| Tabs | Arrow keys move; Home/End jump |
| Combobox | Arrow keys open/navigate; type to filter |
| Radio group | Arrow keys move selection |
For SPAs: move focus to h1 or main landmark on route change so screen-reader users know the
view changed. Don't rely on visual swap alone.
Assistive tech reads the accessibility tree, not your CSS.
<label for> or wrapping label. Placeholder
is not a label.aria-label, or aria-labelledby.
Decorative icons: aria-hidden="true".alt text, or alt="" if purely decorative. Complex charts need a text
summary or long description.aria-expanded, aria-selected, aria-checked,
aria-current, disabled, aria-disabled, aria-invalid.<fieldset>/<legend> or role="group" + aria-labelledby.aria-describedby (hint text, character count, format example).<input id="email" aria-describedby="email-hint email-error" aria-invalid="true" />
<p id="email-hint">We'll never share this.</p>
<p id="email-error" role="alert">Enter a valid email address.</p>
Visual updates that happen without navigation must be communicated.
role="status" or aria-live="polite". Don't steal focus for
non-critical confirmations.role="alert" or aria-live="assertive". Move focus to the
error summary or first invalid field on submit.aria-busy="true" on the updating region; use aria-live="polite" for completion
when content replaces a skeleton.Avoid over-announcement: one live region per logical update, not on every keystroke.
prefers-reduced-motion: disable or shorten non-essential animation; keep essential feedback
(focus ring, progress) without parallax, auto-play, or vestibular triggers.user-scalable=no or maximum-scale=1.For layout and responsive behavior beyond a11y, see [[ui-craft]].
Forms are where most real-world a11y failures show up.
required or aria-required="true".autocomplete values so browsers and assistive tech can help.aria-describedby; set aria-invalid="true" on the field.role="alert" or tabindex="-1")
listing linked errors, then let the user jump to each field.These fail often — implement to APG spec or use a battle-tested library.
| Pattern | Must-haves |
|---|---|
| Modal / dialog | Focus trap, Esc closes, aria-modal="true", labelled by title, restore focus to trigger |
| Disclosure / accordion | aria-expanded on trigger; panel content in DOM or moved focus when opened |
| Tabs | role="tablist", roving tabindex, aria-selected, keyboard arrows |
| Combobox / autocomplete | Listbox pairing, active descendant or roving focus, announce result count |
| Data table | <th scope>, captions or aria-label, sort state exposed |
| Carousel | Pause control, no auto-advance (or respect reduced motion), slides labelled |
| Drag and drop | Keyboard alternative to reorder/select — never the only path |
If you use a component library, verify it implements these — many "accessible" components don't.
Automated tools catch roughly 30–50% of issues. "Passes axe" is necessary, not sufficient.
Automated (run in CI when possible):
Manual — do every time:
Document known gaps if you ship with them — don't pretend untested areas are fine.
<div>/<span> instead of <button> or <a>outline: none without replacementtabindex values; tab order that jumps illogically; keyboard trapsalt textaria-hidden on focusable or interactive contenth1, ordered headings, skip link, and correct langalt