メニュー
Use when building or reviewing interactive UI that must meet WCAG 2.2 AA — focus management, ARIA roles and states, keyboard navigation, labels, and visible focus. Covers the accessibility mistakes agents make most.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Use when building authentication UI — login, signup, forgot/reset password, email verification, and OAuth buttons. Covers layout, validation, security-conscious UX (no user enumeration), and loading/error states.
Use when building pricing tables, plan cards, paywalls, and upgrade prompts. Covers monthly/annual toggles, highlighting the recommended plan, usage limits, feature gating UI, and clear upgrade CTAs.
Use when structuring React components in a SaaS app — composing shadcn/ui, cva variants, compound components, controlled vs uncontrolled state, and knowing when to abstract versus inline.
Use when building a dashboard or overview page — stat/KPI cards, chart placement, responsive grids, and a scannable hierarchy. Covers metric cards with deltas, where charts go, and loading/empty states for data.
Use when building data tables — sorting, filtering, pagination, row selection and bulk actions with TanStack Table + shadcn/ui, plus the loading, empty, and error states tables almost always forget.
Use when setting up a design system — color, typography, and spacing scales as CSS variables, the shadcn/ui theme, and dark mode. Covers semantic tokens, Tailwind wiring, and consistent theming across components.
SOC 職業分類に基づく
| name | accessible-components |
| description | Use when building or reviewing interactive UI that must meet WCAG 2.2 AA — focus management, ARIA roles and states, keyboard navigation, labels, and visible focus. Covers the accessibility mistakes agents make most. |
Accessibility is not a feature you add later — it's how you build interactive elements from the start. The single best move in a SaaS app is to use real semantic elements and Radix/shadcn primitives, which ship correct ARIA and keyboard behavior. Most a11y bugs come from re-inventing a button or dropdown with a <div>.
<div onClick> is standing in for a button.// ✗ Inaccessible: no focus, no Enter/Space, no role
<div onClick={save} className="btn">Save</div>
// ✓ Accessible for free
<button type="button" onClick={save} className="btn">Save</button>
A native <button> is focusable, fires on Enter/Space, and announces as a button. Same for <a> (navigation), <label> (form association), <nav>/<main>/<header> (landmarks).
<Label htmlFor="email">Email</Label>
<Input id="email" type="email" />
// Icon-only buttons need an accessible name:
<Button size="icon" aria-label="Close">
<X className="h-4 w-4" aria-hidden />
</Button>
Decorative icons get aria-hidden; the control gets aria-label.
Never outline-none without a replacement. Use a focus ring on every interactive element:
className="focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2"
:focus-visible shows the ring for keyboard users without flashing it on mouse clicks.
tabindex > 0).Esc closes overlays; Enter/Space activate; arrow keys move within menus/tabs/radios.DropdownMenu, Dialog, Tabs, Select) implement these — prefer them over hand-rolled widgets.Screen readers miss silent DOM updates. Use live regions for async status:
<p role="status" aria-live="polite">{saving ? "Saving…" : "All changes saved"}</p>
Toasts should render in an aria-live region (sonner/shadcn handle this — see notifications-and-toasts).
aria-label.alt; decorative ones alt=""/aria-hidden.<div onClick> instead of <button> — no keyboard, no role.outline-none with no focus replacement — keyboard users get lost.The accessibility baseline every other skill assumes — forms-and-validation, modals-and-dialogs, and navigation-patterns all build on these rules.