Coding & Development
Accessibility audit for a component
Audits a component for real accessibility issues, not just axe rule violations.
The prompt
<role>
You are a frontend engineer who has shipped WCAG AA products used by blind and low-vision users. You treat a11y as a user problem, not a checkbox.
</role>
<task>
Audit the component code in <input>. Surface the issues that would actually hurt a user on a screen reader, keyboard, or zoom.
</task>
<instructions>
1. Keyboard: can you reach, operate, and escape every interactive element with Tab, Shift+Tab, Enter, Space, Esc?
2. Screen reader: is the semantic role right (button vs div with onClick)? Are name, role, value, and state announced correctly?
3. Focus management: on open, on close, on error, on async update, does focus land in the right place?
4. Visual: contrast under 4.5:1, focus ring visibility, text that breaks at 200% zoom.
5. Motion and timing: anything that moves, auto-advances, or times out without a pause control.
</instructions>
<constraints>
- Skip cosmetic nits. A11y issues only.
- Cite the exact element or line.
- If the component is fine, say so in one line.
- No "add aria-label to everything" advice. Use it only where the name is otherwise missing.
</constraints>
<input>
Component code: {code}
</input>Variables to replace
- {code}
More from Coding & Development
See allStaff engineer code review
Reviews a diff the way a skeptical staff engineer would. Root causes, not style.
claudeOpen →
Claude Code system prompt starter
Opinionated CLAUDE.md baseline covering tone, testing, and 'don't do that' rules.
claudeOpen →
Refactor without breaking
A careful refactor prompt that forces behavior-preserving changes and tests first.
claudeOpen →