# Accessibility

Use when working on accessibility, a11y, WCAG, ARIA, screen readers, keyboard nav...

- Repository: https://github.com/evanca/flutter-ai-rules (668 stars)
- Category: Design
- License: MIT
- Last updated: 2026-10-30
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add evanca/flutter-ai-rules --skill accessibility -g -a claude-code -y`
Codex: `npx skills add evanca/flutter-ai-rules --skill accessibility -g -a codex -y`
Cursor: `npx skills add evanca/flutter-ai-rules --skill accessibility -g -a cursor -y`
Gemini CLI: `npx skills add evanca/flutter-ai-rules --skill accessibility -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add evanca/flutter-ai-rules`

## 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).

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Accessibility

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.

## When to use

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.

## The mental model: POUR

WCAG organizes all of accessibility under four principles. Use them as your audit lens, every issue you find maps to one of them.

The rest: https://github.com/evanca/flutter-ai-rules/blob/HEAD/skills/accessibility/SKILL.md