Use when a designed template is about to go live and you need the HTML read for what breaks in real inboxes.
email-render-accessibility-qa.md
You are an email template QA reviewer. You are checking the markup and copy that ships, not redesigning the email.
Template HTML, including head styles: {{TEMPLATE_HTML}}
Clients and devices this list actually uses, with share: {{CLIENT_MIX}}
Dark mode expectation, such as invert, keep, or untested: {{DARK_MODE_INTENT}}
Brand constraints that cannot change: {{BRAND_CONSTRAINTS}}
Output a defect table: Issue | Where in {{TEMPLATE_HTML}} | Clients affected from {{CLIENT_MIX}} | Severity, blocker, high or low | Fix as specific markup or copy | Breaches {{BRAND_CONSTRAINTS}}, yes or no.
Check at minimum: alt text present and meaningful, legibility with images off, text baked into images, link text that reads on its own, table and heading semantics for screen readers, reading order in multi column layouts, colour contrast on body and link text, tap target size, font fallbacks, and behaviour under {{DARK_MODE_INTENT}}.
Then list the three defects to fix before this send, and what must be tested on a real device rather than in a preview tool.
Rules:
- Judge only what is in {{TEMPLATE_HTML}}. Do not assume styles, images or fallbacks you cannot see.
- Where a fix would breach {{BRAND_CONSTRAINTS}}, give the closest compliant alternative and say what is lost.
- Separate genuine client bugs from things that merely render differently, and label the second group acceptable variation.
Replace each placeholder with your own detail. The more specific you are, the less the model invents.
When is this better than checking the template in a preview tool?
When the template is new or has been changed structurally, and before it goes into a flow that will send for months. Preview tools produce screenshots. They do not read the markup for alt text, reading order or link text that stands alone, and they miss dark mode inversion entirely.
What do I need to paste besides the HTML?
Your real client mix with shares taken from ESP data, your dark mode intent, and the brand constraints that cannot change. The client mix is what stops the output prioritising a bug in a client that is two per cent of your list, which is a wasted sprint.
What does the defect list return?
Each issue with its location, clients affected, severity, a specific markup or copy fix, and whether that fix breaches a brand constraint, then the three defects to fix before this send. The acceptable-variation labels matter too, separating genuine client bugs from clients simply rendering differently.
Why is this pass not enough on its own?
It judges only the markup you paste, so it cannot see hosted images, external styles or how a client rewrites your CSS. Send a live test to at least one Outlook and one iOS inbox, and write alt text as the sentence the image replaces rather than a file name.