Verified against ChatGPT · 2026-08-11
Turn a WCAG pass into a severity-ranked fix list engineers will actually act on
Reviews a screen or component against WCAG success criteria and outputs a severity-ranked list of concrete fixes rather than an undifferentiated wall of citations, so accessibility work gets triaged like any other bug backlog.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are auditing the described screen or component against WCAG 2.2 success criteria, but I don't want a wall of citation numbers — I want a severity-ranked, engineer-actionable fix list, the same way a bug backlog would be triaged. WHAT'S BEING AUDITED A custom date-picker component used in a hotel booking flow's check-in/check-out step. CODE OR MARKUP DETAILS AVAILABLE Built as a <div> grid of clickable <span> cells with onClick handlers; no visible focus outline; no aria-label on the calendar container. KNOWN ASSISTIVE-TECH USERS IN YOUR AUDIENCE Support tickets mention at least two screen-reader users unable to select dates; no data on other assistive tech. RULES For every issue you find, name the specific WCAG success criterion it relates to, but do not treat the citation itself as the deliverable — the deliverable is: what breaks for a real assistive-technology user, and what to change in the markup or design to fix it. Rank severity by real user impact, not by how many criteria a given issue happens to touch: an issue that makes an entire flow unusable with a screen reader (e.g., a custom dropdown with no keyboard path and no accessible name) is Critical even if it maps to only one criterion, while a cosmetic contrast ratio that's off by a fraction of a point on non-essential decorative text is Low even if it's a clean technical violation. Where the audit depends on facts you don't have — the actual DOM structure, whether a library component already handles ARIA roles internally, current contrast ratios you can't measure from a description alone — say so explicitly and describe what you'd check rather than asserting a violation you can't actually confirm. Do not state that any of this constitutes legal compliance sign-off; frame every finding as a technical audit for engineers, not a determination of whether the product meets any specific regulation, since that determination requires verification beyond what a text description can provide. OUTPUT FORMAT A table: Severity (Critical / Serious / Moderate / Low) | Issue | Affected users | Relevant WCAG criterion | Concrete fix. Sort by severity. End with a short list of anything you flagged as "can't confirm from this description" and what to check to confirm it.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A WCAG audit prompt without a severity framework tends to produce a flat list of citation numbers ordered by whichever success criteria the model happens to recall first, which reads as thorough but gives an engineering team no way to decide what to fix this sprint versus next quarter — severity has to be forced explicitly because the WCAG spec itself doesn't rank criteria by real-world user impact, it organizes them by conformance level (A/AA/AAA), which is a compliance concept, not a triage concept, and the two frequently diverge (a Level A keyboard-trap issue that blocks an entire flow is far more severe in practice than a Level AA contrast nuance on secondary text). Requiring the model to distinguish "can't confirm from this description" from a stated finding directly counters GPT-5.1's tendency to assert a specific violation (like a contrast ratio) with false precision when given only a text description and no actual computed color values or rendered DOM — asking for that explicit uncertainty flag produces a genuinely more trustworthy audit than one that states every finding with equal unwarranted confidence. The instruction to frame findings as a technical audit rather than compliance sign-off matters because a WCAG success-criterion citation is a technical fact, but whether a product satisfies a specific accessibility law (ADA, EN 301 549, or otherwise) is a legal determination outside what any text-based review can establish, and conflating the two would misrepresent an engineering triage document as something with legal weight it doesn't have.
What you get back
Critical | Date cells are non-focusable spans with only onClick handlers, no keyboard access at all | Keyboard-only and screen-reader users cannot select any date | WCAG 2.1.1 (Keyboard) | Convert cells to native <button> elements or add tabindex and key handlers for Enter/Space/arrow-key navigation. Can't confirm from this description: actual rendered contrast ratio of the selected-date highlight color — check with a contrast-checking tool against the real hex values.
Verified against
ChatGPT GPT-5.1 · 2026-08-11
Changelog
- 2026-08-11 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — branding & design, built and maintained for you — that's Scult's day job.
EXPLORE BRANDING & DESIGN
