Accessible email design: a template checklist beyond alt text

Imagine a welcome email delivering a beginner’s guide. A beautiful hero can set the mood, but the guide’s name and download action should not exist only inside it. Put the title, a short explanation, and the link in HTML text. If remote images fail, the email should still answer three questions: who is writing, what is useful here, and what can I do next?

Start the design review with images disabled. Remove the visual scaffolding and read what remains aloud. A blank rectangle followed by ‘click here’ fails this exercise even if the normal preview looks polished. Keep material terms beside the action rather than embedded in a promotional image. Provide a plain-text alternative with the same essential information and destinations; it is a separate artifact that can also drift during revisions.

W3C’s image guidance distinguishes information, decoration, and function. Apply that distinction deliberately: an ornamental squiggle can have an empty alternative; an informative illustration needs its essential meaning; a linked image should communicate its destination or action. Avoid repeating a nearby caption word for word when it adds no useful information.

For our welcome example, the guide cover might say ‘Beginner’s guide to planning your first campaign’ if that identifies the resource. A decorative confetti image should not announce a long list of shapes. If the image is the only link, a useful alternative is ‘Download the beginner’s campaign guide,’ not ‘yellow book.’ For charts, place the important finding and supporting figures in accessible text nearby. Do not expect one enormous alt attribute to replace a readable explanation of complex data.

Reference: W3C WAI: Images tutorial

A visual two-column composition can conceal a confusing source order. Read the DOM sequence or inspect the message with a screen reader: sender context, title, explanation, primary action, supporting information, footer. Avoid stitching sentences across unrelated cells. Layout tables are a compatibility technique, not a reason to give decorative structure the semantics of a data table.

Use real headings for meaningful sections and choose their levels coherently. Declare the message’s language in the HTML, including substantial language changes where the output supports them. For a simple welcome, one heading and one action may be enough. Keep link labels distinct: ‘Download the guide’ and ‘Manage email preferences’ communicate different destinations before someone opens either. Keyboard-test the actual delivered message as well as the browser preview, because host clients can transform markup and focus behavior.

Reference: W3C WAI: Headings

W3C’s minimum-contrast criterion uses 4.5:1 for ordinary text and 3:1 for qualifying large text, with specified exceptions. Use those reference thresholds during design rather than assuming a brand palette is accessible in every combination. Yellow can be an excellent background with dark text and a poor foreground on cream. Check the actual pair, including secondary text and button labels.

Then enlarge the message and inspect a narrow viewport. Long link labels should wrap, text should remain readable, and the primary action should not slide off-screen. Avoid fixed-height text containers that crop a translated or enlarged sentence. Do not communicate a deadline, error, or status through color alone. A red dot can accompany ‘Payment failed’; it should not replace those words. Test dark mode separately, since client transformations may change a previously acceptable pair.

Reference: W3C: Contrast (Minimum)

Our hypothetical email starts with ‘Your campaign guide is ready,’ followed by two sentences about what the reader requested and one download link. The cover is supportive, not the container for the message. A short support sentence and an identifiable preferences footer follow. The greeting has a neutral fallback when a name is missing; no essential information depends on personalization.

Review the real output after variables resolve. A template can pass with a short sample name and break with a long one. Include missing, long, and non-Latin values in your fixtures. Ask a reviewer to find the resource with images off, then to navigate links without a mouse. Record what failed and the client used. That evidence is more actionable than a single green accessibility score.

• The resource name and action remain readable without images.
• Link labels identify their destinations out of context.
• Heading and reading order make sense when read aloud.
• Large text and narrow layouts do not crop useful content.
• The plain-text message agrees with the HTML message.

If an agent edits the welcome template, include accessibility in its brief. Protect the download destination, required footer, and semantic structure. Ask it to propose image alternatives and explain the function each serves. A model can help with wording, but its statement that a template is accessible is not a test result. Re-run checks after a meaningful revision.

Save the template revision, resolved fixture data, reviewer notes, and client evidence together. Distinguish a simulated preview from a real-client capture; a browser screenshot cannot establish behavior in every mailbox. Start with a Moosewave template, retain its useful structure, and make this checklist part of the release decision. The goal is not a special accessible edition. It is one message that stays useful across different readers and conditions.

• W3C WAI: Images tutorial. Image alternatives classified by purpose. The welcome-message review is our applied example.
• W3C WAI: Headings. Semantic headings and coherent document structure.
• W3C: Contrast (Minimum). Reference contrast thresholds and exceptions; not a certification of email-client behavior.

Sources checked 11 October 2026. Product behavior and documentation can change, so the linked primary source takes precedence if it differs from this article.