Accessibility (a11y)
SkillAI & modelsThis skill lets your AI audit a user interface for accessibility problems against the WCAG standard. Once added, your AI can review screens you are building or changing and flag issues with keyboard access, contrast, ARIA, and screen reader support before you ship.
Available today. Use it from your connected AI after setup.
No other account needed.
Add the skill, then ask your AI to check the screen or component you are working on. It fits best while building or changing UI, or as a final check before shipping a user-facing screen.
Then ask your AI: use the Accessibility (a11y) skill
What your AI can do with it
- Check that pages use semantic HTML so assistive tools understand the structure
- Find controls keyboard users cannot reach or operate
- Flag text and background color pairs with poor contrast
- Review ARIA labels and roles for mistakes
- Check that keyboard focus moves sensibly when the interface changes
- Assess how well a screen reader can interpret the interface
What this skill tells your AI
The instructions your AI receives, as published by byerlikaya/claude-starter-kit in plugin/skills/a11y/SKILL.md and read by ahel’s review.
Trigger phrases: "a11y", "accessibility", "WCAG", "screen reader", "keyboard navigation", "contrast", "ARIA", "keyboard only", "with a keyboard", "keyboard focus", "without a mouse", "focus ring", "tab order", "alt text", "color blind", "colour blind", "voiceover", "talkback", "reduced motion"
Goal: make the interface usable by everyone, including keyboard, screen reader, and low vision. Baseline target: WCAG 2.1 AA. Stack-agnostic (web/React/RN); do a web search when needed for framework-specific APIs.
Checklist
- Semantic HTML:
button/a/nav/main/h1..h6correct; nodiv-buttons - Keyboard: every interaction reachable via Tab, sensible order, visible focus ring
- Focus management: focus moves on modal/route change, focus trap correct
- Contrast: text ≥ 4.5:1, large text ≥ 3:1
- Alt text:
alton meaningful images;alt=""on decorative images - Forms: every input has a
label; error message programmatically linked (aria-describedby) - ARIA: only when needed; wrong ARIA is worse than no ARIA; role/name/state correct
- Motion/animation: respect
prefers-reduced-motion - Language:
<html lang>correct (coordinate with i18n)
How
- Start with semantics — the right element solves 80%. Use
buttoninstead ofrole="button"+div. - Navigate with the keyboard — drop the mouse, run the whole flow with Tab/Shift-Tab/Enter/Escape; is focus visible and its order sensible.
- Naming — does every interactive element have an accessible name (
aria-labelon visual-only icon buttons). - Contrast — check color pairs against the ratio; don't convey meaning by color alone (add an icon/text).
- Dynamic content — notify the screen reader via a live region (
aria-live); manage modal focus. - Automated + manual — tools like linters/axe are the baseline; but manual keyboard+reader testing is essential (tools don't catch 100%).
React / RN note
- Web React: semantic element in JSX +
htmlFor/aria-*; usebuttoninstead of a clickablediv. - React Native:
accessible,accessibilityLabel,accessibilityRole,accessibilityState(coordinate withfrontend-rn-expo).
Invariant rules
- Semantics first, ARIA second — wrong ARIA does harm.
- Must be fully usable by keyboard — without a mouse.
- Color cannot be the sole carrier of meaning.
- Automated tools are not enough — manual keyboard+reader testing.
- Follow the existing design system — if there is a component library, keep its accessible pattern.
Signals
- GitHub stars
- 22
- Forks
- 4
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
a11y- Source
- github.com/byerlikaya/claude-starter-kit