{"id":"evanca-accessibility","name":"accessibility","summary":"アクセシビリティ、a11y、WCAG、ARIA、スクリーンリーダー、キーボードナビ、フォーカスオーダー、コントラスト、代替テキスト、字幕、モーション削減、ターゲットサイズの作業時に使用;言語や文化、デバイス(インクルーシブデザインを参照)ではありません。","body":"# Accessibility\n\nAccessibility answers one question:\n\n> **Can someone use this with assistive tools, a different input method, or a different ability?**\n\nIt 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.\n\n## When to use\n\nUse 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.\n\n**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.\n\n## The mental model: POUR\n\nWCAG organizes all of accessibility under four principles. Use them as your audit lens — every issue you find maps to one of them.\n\n- **Perceivable** — users can sense the content through *some* channel. Don't rely on one sense alone. (Text alternatives for images, captions/transcripts for audio and video, sufficient color contrast, not using color alone to convey meaning, content that reflows and survives zoom.)\n- **Operable** — users can drive the interface with *whatever input they have*. (Everything reachable and usable by keyboard, visible focus, no keyboard traps, adequate target sizes, generous or adjustable time limits, nothing that flashes in a seizure-inducing way.)\n- **Understandable** — users can predict and comprehend behavior. (Clear labels, instructions, and error messages; consistent navigation; predictable interactions; readable language.)\n- **Robust** — assistive tech can actually parse it. (Valid semantic structure; correct name/role/value on every control; native semantics first, ARIA only to fill gaps.)\n\nA 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.\n\n## Who and what you are designing for\n\nDesign for the assistive tools and input methods people actually use, not an abstract \"disabled user\":\n\n- **Screen readers** (VoiceOver, TalkBack, NVDA, JAWS) — need correct semantics, reading order, labels, and announcements of dynamic changes.\n- **Keyboard-only and switch users** — need a logical focus order, visible focus, and no mouse-only interactions.\n- **Voice control** — needs visible, speakable labels that match the accessible name.\n- **Screen magnification and zoom** — needs layouts that reflow without horizontal scrolling or clipping at 200%+.\n- **Captions / transcripts users** — Deaf and hard-of-hearing users, *and* anyone in a loud or silent environment.\n- **People with cognitive and learning disabilities** — need clear language, low memory load, and forgiving flows (see below).\n\nNote the recurring pattern: most of these help far more people than the group they target — the same insight that drives inclusive design.\n\n## Fast audit checklist\n\nWalk these in order; each line is a concrete thing to check or fix.\n\n1. **Keyboard** — Tab through the whole flow. Is every control reachable and operable? Is focus visible? Is the order logical? Can you get trapped?\n2. **Screen reader** — Does every control announce a meaningful name and role? Are images given text alternatives (or marked decorative)? Are dynamic updates (errors, loading, toasts) announced?\n3. **Contrast & color** — Does text meet contrast minimums (4.5:1 body, 3:1 large)? Is any meaning carried by color alone (e.g., red = error with no icon/text)?\n4. **Structure** — Are headings, lists, landmarks/regions, and labels semantic rather than visual-only? Does reading order match visual order?\n5. **Forms & errors** — Is every field labeled (not placeholder-only)? Are errors identified in text, tied to their field, and explained with how to fix?\n6. **Targets & timing** — Are tap targets large enough and spaced? Are time limits absent, generous, or adjustable? Is autosave used to prevent data loss?\n7. **Media & motion** — Captions/transcripts for audio/video? Does the UI honor reduced-motion preferences? Nothing flashing more than ~3×/second?\n8. **Zoom/reflow** — At 200% zoom (or large system font), does content reflow without clipping or horizontal scroll?\n\n## Beyond conformance: cognitive accessibility\n\nWCAG 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.\n\nRead **[references/cognitive-accessibility.md](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.\"\n\n## Motion, sensory, and age-related needs\n\nAnimation 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.\n\nOlder 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.)\n\nRead **[references/motion-and-sensory.md](references/motion-and-sensory.md)** for `prefers-reduced-motion` patterns (with code), photosensitivity limits, and the older-user ability overlap.\n\n## How to verify\n\nAutomated 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.\n\n## References\n\nLoad these only when the task calls for the depth:\n\n- [references/cognitive-accessibility.md](references/cognitive-accessibility.md) — W3C COGA: the 8 objectives and their design patterns (beyond WCAG).\n- [references/motion-and-sensory.md](references/motion-and-sensory.md) — reduced motion (with CSS example), photosensitivity, older-user ability overlap.\n\nPrimary sources:\n\n- [Accessibility, Usability, and Inclusion — W3C WAI](https://www.w3.org/WAI/fundamentals/accessibility-usability-inclusion/)\n- [Making Content Usable for People with Cognitive and Learning Disabilities (COGA) — W3C](https://www.w3.org/TR/coga-usable/)\n- [Older Users and Web Accessibility — W3C WAI](https://www.w3.org/WAI/older-users/)\n- [prefers-reduced-motion — MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion)","author":"@evanca","ownerProfile":null,"authorContacts":null,"sourceUrl":"https://github.com/evanca/flutter-ai-rules/tree/main/skills/accessibility","license":"MIT","category":"review","lang":"en","tokens":1734,"stars":0,"calls30d":3,"claimed":false,"visibility":"public","origin":"crawler","version":"0.1.0","createdAt":"2026-08-22","updatedAt":"2026-08-22","files":[{"path":"references/cognitive-accessibility.md","size":5022,"sha256":"3d0a1c6929035ee5518a0e9fb396c6b4bb13074114db7d960bb1c77217c19b04"},{"path":"references/motion-and-sensory.md","size":4324,"sha256":"5a48b7be6e6697afff75862f89b3b8a6a615f9d98c4d74f8b78aa332d2691347"}],"requires":{"mcp":[],"tools":[]},"safety":{"flags":[],"scannedAt":"2026-08-22","hasScripts":false,"networkEndpoints":[]}}