メニュー
Use when working on accessibility, a11y, WCAG, ARIA, screen readers, keyboard nav, focus order, contrast, alt text, captions, reduced motion, or target sizes; not language/culture/device (see inclusive-design).
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when creating a feature, designing folder structure, adding repositories/services/view models, wiring dependency injection, or deciding which layer owns logic.
Use when creating a Cubit or Bloc, modeling state with sealed classes or status enums, wiring BlocBuilder/BlocListener/BlocProvider, writing bloc tests, or choosing between Cubit and Bloc.
Use when asked to review a PR, MR, branch, or diff, audit changed files, or check code quality.
Use when writing switch statements, refactoring if-else chains, creating data classes, choosing records vs classes, destructuring values, or modernizing pre-Dart-3 code.
Use when writing Dart code, reviewing for style, refactoring naming, adding doc comments, structuring imports, or enforcing type annotations.
Use when setting up firebase_ai, generating text/chat with Gemini, streaming AI output, building multimodal prompts, or handling AI errors.
| name | accessibility |
| description | Use when working on accessibility, a11y, WCAG, ARIA, screen readers, keyboard nav, focus order, contrast, alt text, captions, reduced motion, or target sizes; not language/culture/device (see inclusive-design). |
Accessibility answers one question:
Can someone use this with assistive tools, a different input method, or a different ability?
It is specifically about people with disabilities being able to perceive, understand, navigate, and interact with a product on equal terms — whether they use a screen reader, only a keyboard, a switch, voice control, magnification, or captions. This is the ability half of designing for everyone. The context half — language, culture, device, affordability, confidence — belongs to the sibling inclusive-design skill. They overlap but have different focuses; keep them distinct so neither gets diluted.
Use this skill when the task involves any of: WCAG conformance, ARIA, semantic markup, screen-reader support, keyboard/focus management, color contrast, text alternatives (alt text, captions, transcripts), accessible forms and error messages, target sizes, timing/timeouts, motion sensitivity, or cognitive accessibility. Also use it whenever someone asks to "make this accessible," run an a11y audit, or check whether a disabled user can complete a task.
When not to use it: if the real concern is who gets left out by context — non-English speakers, people on cheap phones or slow networks, people who can't afford data, first-time or anxious users, or global name/address formats — that is inclusion, not accessibility. Switch to the inclusive-design skill.
WCAG organizes all of accessibility under four principles. Use them as your audit lens — every issue you find maps to one of them.
A useful test for any element: if I could not see it, hear it, use a mouse, or read quickly — could I still complete this task? If the answer is no under any of those, you've found the principle that's failing.
Design for the assistive tools and input methods people actually use, not an abstract "disabled user":
Note the recurring pattern: most of these help far more people than the group they target — the same insight that drives inclusive design.
Walk these in order; each line is a concrete thing to check or fix.
WCAG alone does not cover everything people with cognitive and learning disabilities (dyslexia, ADHD, autism, dementia, aphasia, memory or attention differences) need. The W3C COGA guidance is supplemental, not required for WCAG conformance, and it is where the highest-leverage improvements for the largest hidden population usually live: clear language, consistent design, single-step instructions, not relying on memory, forgiving error recovery, and minimizing distraction.
Read references/cognitive-accessibility.md for COGA's eight objectives and their concrete design patterns when the task touches readability, complex flows, forms, logins, or "this is confusing/overwhelming."
Animation and motion can cause real harm (nausea, dizziness, loss of focus) for people with vestibular disorders, and seizures for people with photosensitivity. Honor the user's prefers-reduced-motion setting — reduce or replace motion rather than removing all feedback.
Older users are a large group whose age-related changes in vision, dexterity, hearing, and memory overlap directly with disability needs — designing well here helps everyone age into your product. (Treat age as a context/identity dimension — first-time confidence, life stage — in the inclusive-design skill; treat age-related ability change here.)
Read references/motion-and-sensory.md for prefers-reduced-motion patterns (with code), photosensitivity limits, and the older-user ability overlap.
Automated checkers (axe, Lighthouse, Accessibility Scanner, etc.) catch maybe a third of issues — necessary but never sufficient. Always add manual checks: navigate the real flow with the keyboard only, then again with a screen reader, then with the OS reduced-motion and large-text settings on. The bug a tool can't catch — a focus order that makes no sense, a label that lies — is usually the one that actually blocks someone.
Load these only when the task calls for the depth:
Primary sources:
