Verified against Claude · 2026-07-25
Run an accessibility audit on a component before it ships
A component-level a11y audit that checks role-specific WCAG success criteria against the actual JSX, not a generic "add aria-label everywhere" pass, and states plainly what static code review cannot verify.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are auditing a single React component for accessibility issues that would actually fail a screen-reader or keyboard-only user, not producing a generic checklist that would apply equally to any component. COMPONENT A custom Dropdown component built from a styled div with an onClick handler, an absolutely positioned list of divs for options, and no keyboard handling of any kind. COMPONENT TYPE combobox / custom select dropdown TARGET CONFORMANCE LEVEL AA KNOWN USER REPORTS A support ticket says a screen-reader user could not tell which option was currently selected. AUDIT FOCUS For this specific component type, check the following, and only flag issues that actually apply to what this component is: keyboard operability — can every interactive element be reached and operated with Tab, Shift+Tab, Enter, Space, Escape, and arrow keys as appropriate for its role, with no keyboard trap that leaves focus stuck inside. Focus management — if this is a modal, menu, or disclosure, does focus move to the correct place on open and return to the trigger element on close. Semantics — does it use the correct native element or ARIA role for what it actually is, rather than a styled div with an onClick handler standing in for a button or a link. Name and state exposed to assistive technology — does every control have an accessible name, and do state changes such as expanded, collapsed, selected, or invalid get exposed through ARIA attributes and not only through a visual change. Color and motion — is any information conveyed by color alone, and does any animation respect prefers-reduced-motion. Touch and zoom — for any component likely to be used on a touch device, are interactive targets at least roughly 24 by 24 CSS pixels per WCAG's target-size guidance, and does the layout stay usable rather than clipping or overlapping when the page is zoomed or text is resized up to 200%. SEVERITY CALIBRATION Calibrate blocker versus major versus minor by actual user impact, not by how technically precise the WCAG citation sounds. An issue that makes the component completely unusable for a group of users — no way to open it at all via keyboard — is a blocker. An issue that makes it usable but noticeably harder, such as a confusing but not-impossible focus order, is major. An issue that is a real deviation from best practice but causes no concrete failure for any user, such as a redundant ARIA attribute that does not contradict the visual state, is minor. Do not inflate a finding to blocker to seem thorough, and do not downgrade a real keyboard trap to minor just because its fix happens to be a single line — severity reflects user impact, not fix effort. OUTPUT FORMAT Produce a table with these columns: Issue | WCAG criterion, cited by number and name | Who it affects | Severity — blocker, major, or minor | Fix. After the table, list which issues you could not fully assess from static code alone — real rendered color-contrast values, actual screen-reader announcement order, real focus-visible styling — and name the specific manual check that would confirm each one. Do not silently skip this section even if everything else looked clean.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Grounding the audit in component_type is what makes the checklist specific instead of generic: a modal's real failure modes — a focus trap on open, Escape closing it, focus returning to the trigger — are entirely different from a combobox's — arrow-key navigation between options, aria-activedescendant tracking the highlighted item, aria-expanded reflecting open state — and a plain "check accessibility" prompt tends to default to boilerplate aria-label suggestions regardless of what the component actually is, because it has no signal for which failure modes are even relevant here. Citing real WCAG success-criterion numbers keeps every finding falsifiable: a reviewer can look up 2.1.1 Keyboard or 4.1.2 Name, Role, Value and confirm or reject the specific finding, instead of being handed an unverifiable "this might be an issue" that either gets rubber-stamped or ignored. The explicit instruction to name what cannot be assessed from static code alone matters because color contrast against a real rendered background, and actual screen-reader announcement order through a specific screen reader and browser combination, are things a code review genuinely cannot verify from source alone — naming that boundary honestly is what stops the model from confidently asserting a pass or fail it is not actually in a position to make, and gives the reviewer a concrete next action instead of false confidence. The severity-calibration rule matters because severity is the field a rushed review actually acts on — a team triaging a long finding list will fix every blocker and often defer everything else, so a model that inflates minor cosmetic deviations to blocker status to look thorough gets exactly the wrong items fixed first, while one that downgrades a real keyboard trap because the code fix happens to be a single line leaves the actual highest-impact issue sitting in a backlog labeled low-priority. Including touch-target size and reflow-under-zoom as their own explicit checks closes a common gap in audits that quietly treat accessibility as synonymous with screen-reader support: WCAG's target-size and reflow criteria exist specifically for users with limited fine motor control or low vision who never touch a screen reader at all, and a component that passes every keyboard and ARIA check can still fail these users badly if its click targets are a few pixels across or its layout breaks at 200% zoom, a failure mode a screen-reader-only mental model of accessibility will never catch.
What you get back
Issue | WCAG criterion | Who it affects | Severity | Fix Div used as trigger, no role or keyboard support | 2.1.1 Keyboard, 4.1.2 Name/Role/Value | Keyboard and screen-reader users | blocker | Use a real button element with aria-haspopup="listbox" and aria-expanded No focus moves into the option list on open | 2.4.3 Focus Order | Keyboard and screen-reader users | blocker | Move focus to the first option or the listbox itself on open, return focus to the trigger on close Selected option shown only via a checkmark icon | 1.4.1 Use of Color | Low-vision users | major | Add aria-selected and a text or shape cue, not color alone Not assessable from code alone: actual contrast ratio of the checkmark icon against its background — confirm with a contrast checker on the rendered page. Actual screen-reader announcement of the selected state — confirm by testing with VoiceOver or NVDA against the fix above.
Verified against
Claude Sonnet 4.6 · 2026-07-25
ChatGPT GPT-5.1 · 2026-07-23
Changelog
- 2026-07-25 — Initial publish, verified against Claude (Sonnet 4.6) and ChatGPT (GPT-5.1) against WCAG 2.2 AA.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
