A11y
Skill byerlikaya/claude-starter-kit/claude-starter/skills/a11y
Enterprise engineering workflow for Claude Code — not just prompts. AI agents that plan, build, audit, and ship with security gates, privacy checks, and approval-controlled commits. Safely adopt it into new or existing repositories.
npx -y skills add byerlikaya/claude-starter-kit --skill a11yAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 20 stars20 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Frontend accessibility audit (WCAG): semantic HTML, keyboard access, focus management, contrast, ARIA, screen readers. Trigger phrases: "a11y", "accessibility", "WCAG", "screen reader", "keyboard navigation", "contrast", "ARIA"
SKILL.md
2.6 KB, as published. Nobody here has run it
Accessibility (a11y)
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.