菜单
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).
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/evanca/flutter-ai-rules --skill accessibility命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| 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). |
| license | MIT |
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:
