CONVERSION

Accessibility blockers costing conversions

Use when you need the accessibility failures that stop people buying, not a full compliance audit.

accessibility-blockers-costing-conversions.md

Download .md

You are finding accessibility failures that also stop people converting. You are not producing a full WCAG audit or a legal opinion.

PAGE OR FLOW AND ITS CONVERSION ACTION: {{FLOW_AND_ACTION}}
MARKUP, COMPONENT LIST OR SCREENSHOT DESCRIPTION: {{PAGE_STRUCTURE}}
ISSUES ALREADY REPORTED: {{KNOWN_ISSUES}}
ASSISTIVE TECHNOLOGY OR DEVICE NOTES IF ANY: {{AT_NOTES}}

Output a table: Issue | Where in {{FLOW_AND_ACTION}} it occurs | Who it blocks | Stops the conversion outright or only slows it | WCAG criterion if you are confident | Fix | Effort.

Cover at minimum: keyboard reach and a visible focus state on every control, labels tied to inputs, errors announced and not signalled by colour alone, contrast on buttons and helper text, tap target size, custom dropdowns and modals that trap or lose focus, time limits, autoplay and motion, alternative text on images that carry information.

Then:
- Rank by conversion impact rather than severity rating. A submit button unreachable by keyboard outranks a decorative contrast failure.
- List anything in {{KNOWN_ISSUES}} that is already fixed or duplicated, so the backlog stays honest.
- State which findings need a real screen reader or a user test to confirm, given {{AT_NOTES}}.

Constraints: judge only what appears in {{PAGE_STRUCTURE}}. Do not cite a WCAG number you are unsure of, write "criterion unclear" instead. Do not treat an automated checker score as evidence that the flow can be completed. No em dashes.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{FLOW_AND_ACTION}}
{{PAGE_STRUCTURE}}
{{KNOWN_ISSUES}}
{{AT_NOTES}}

Getting a better result

Try the flow yourself with the mouse unplugged before reading the output; it takes five minutes.
Automated tools catch about a third of this, and none of the focus trap problems.
File the outright blockers as bugs rather than as accessibility tickets, or they will queue for a quarter.

Questions about this prompt

When do I use this rather than commission a compliance audit?

When you want the failures that stop people buying rather than a full WCAG report. A compliance audit sorts by severity rating; this ranks by whether the conversion can be completed at all, so a submit button unreachable by keyboard outranks a decorative contrast failure. It is not a legal opinion and does not claim to be.

What do I need in front of me before running it?

The flow and its conversion action, the markup or component list, issues already reported, and any assistive technology notes. Try the flow yourself with the mouse unplugged before reading the output, because five minutes of keyboard testing tells you which findings are real. Automated tools catch about a third and no focus traps.

What comes back, and which part is worth acting on?

A table of issues with who they block, whether the conversion stops outright or only slows, a WCAG criterion only where it is confident, a fix and an effort estimate. The outright blockers ranked by conversion impact are what you act on. It also names the findings needing a real screen reader or a user test.

What is the mistake that costs me here?

Filing the blockers as accessibility tickets, where they queue for a quarter. A control nobody can reach with a keyboard is a broken feature, so file it as a bug. Treating a clean automated checker score as evidence that the flow can be completed is the other trap, and the prompt names it directly.