Quick Accessibility Checks Before You Send

Use this as a first-pass review, not proof that an email is fully accessible. Email clients can alter markup and colors, so combine code checks with manual testing.

  • Message: The essential offer and next step remain understandable when images are blocked.
  • Images: Informative images have useful alternatives; decorative images use alt="".
  • Links: Link text describes the destination or action without relying only on nearby visuals.
  • Structure: The source order makes sense when read linearly, and layout tables are marked presentational where appropriate.
  • Contrast: WCAG AA generally calls for 4.5:1 contrast for normal text and 3:1 for large text. Check actual color combinations.
  • Testing: Inspect the email in representative clients and manually listen to it with a screen reader.

Record the client, device, issue, fix, and retest result for any defect found.

Why Email Accessibility Matters

An email can look polished and still be difficult to use. A promotional headline embedded only in an image may disappear when images are blocked. Repeated “click here” links make navigation harder to understand, and low-contrast text can be difficult to read.

Accessible email development aims to make the message understandable and usable by people with different vision, hearing, motor, and cognitive needs. WCAG is written for web content, not as a single email certification checklist; its relevant principles and success criteria are useful design and testing references, but behavior varies across email clients and assistive technologies.

This guide focuses on practical checks you can apply to table-based marketing emails before sending a campaign.

How WCAG Principles Apply to HTML Email

WCAG groups accessibility requirements under four principles: Perceivable, Operable, Understandable, and Robust. For email work, translate those principles into observable checks:

  • Perceivable: Provide text alternatives for meaningful images, use sufficient contrast, and do not communicate meaning through color alone.
  • Operable: Make links and controls usable with the interaction methods supported by the recipient's email client and device. Keep targets clear and avoid tiny, crowded links.
  • Understandable: Use plain, descriptive language, meaningful link labels, and a logical sequence of content.
  • Robust: Use well-formed HTML and test the message in the clients and assistive technologies your audience is likely to use.

Do not describe an email as “WCAG compliant” solely because a checklist passes. State what was tested, in which clients, and against which criteria. Email rendering and assistive-technology behavior are not identical everywhere.

1. Write Useful Image Alt Text

Alt text should communicate an image's purpose in the context of the message. It does not need to describe every visual detail. If the image conveys a time-limited offer, explain the offer rather than using a file name.

<img
  src="running-shoes-offer.jpg"
  alt="Save 20% on selected running shoes through Sunday"
  width="600"
  style="display:block;width:100%;max-width:600px;height:auto;border:0;"
>

For an image that is the only content inside a link, its alternative should usually make the action clear. Avoid repeating the same message in adjacent visible text if that would create a redundant announcement.

<a href="https://example.com/running-shoes">
  <img src="running-shoes-offer.jpg"
       alt="Shop selected running shoes at 20% off"
       width="600" style="display:block;border:0;">
</a>

Replace sample URLs and offers with the real campaign details. Recheck alt text whenever the offer or creative changes.

2. Mark Decorative Images Correctly

Images that add no information—such as a decorative divider or flourish—should generally have an empty alternative so they do not interrupt the reading experience.

<img src="divider.png" alt="" width="600"
  style="display:block;width:100%;height:auto;border:0;">

An empty alt attribute is the key signal for a decorative image. Avoid verbose descriptions for ornaments. Use aria-hidden only after verifying its support and behavior in the email clients and assistive technologies you target; it is not a substitute for correct alternative text.

4. Create a Logical Reading Order

Arrange the HTML source so the message makes sense when read from top to bottom, even if a client stacks columns or strips styling. Use real heading elements when supported by your email template and verify how they are announced in target clients. Support varies, so do not rely on visual styling alone to convey hierarchy.

Keep paragraphs concise, use lists for genuine groups of items, and avoid spaces or repeated punctuation to simulate columns. Check that the main offer and primary CTA appear in a sensible order in the markup—not only in the desktop visual layout.

5. Use Layout Tables Without Losing Meaning

Tables remain common in HTML email layouts because many email clients support them. When a table is used only to position content, mark it as presentational where appropriate so assistive technology is less likely to treat it as a data table.

<table role="presentation" width="100%" cellpadding="0"
  cellspacing="0" border="0">
  <tr>
    <td>Email layout content</td>
  </tr>
</table>

Do not apply presentation semantics to a table that communicates real data, such as a schedule or price comparison. For a genuine data table, use clear row or column headers and test the result in relevant screen readers and email clients.

6. Check Color Contrast and Dark Mode

For WCAG AA, the usual minimum contrast ratio is 4.5:1 for normal text and 3:1 for large text. These are contrast criteria, not a requirement that every email use a particular font size. Logos and some other visual elements have different rules.

  • Measure actual text and background color pairs, including button text.
  • Check footer and disclaimer text; small, low-contrast copy is easy to miss.
  • Use underlines or other non-color cues where needed to identify links.
  • Preview dark mode in the clients your audience uses. Some clients transform colors, so a pair that passes in light mode may not remain readable.

Dark-mode behavior differs by client. Use real previews and contrast measurements rather than assuming your CSS will be applied consistently. See the dark mode email development guide.

7. Test with Screen Readers

Automated checks can catch issues such as missing attributes, but they cannot reliably tell you whether the whole message is understandable when spoken aloud. Perform a manual pass using NVDA on Windows or VoiceOver on Apple devices, paired with representative email clients where possible.

Listen for whether the main message is announced in a sensible order, meaningful images communicate their purpose, decorative images are skipped, links have distinct names, layout tables create distracting announcements, and headings or lists help navigation.

Record the client, operating system, screen reader, and relevant settings alongside each finding. This makes results reproducible and avoids treating one setup as representative of every recipient.

8. A Repeatable Email Accessibility QA Workflow

  1. Inspect content: Check that the key offer, terms, and CTA make sense without images or styling.
  2. Review markup: Check image alternatives, link labels, heading structure, reading order, and table roles.
  3. Measure contrast: Check normal and large text against actual backgrounds; repeat for relevant dark-mode appearances.
  4. Preview clients and devices: Include the email clients that matter to your audience, such as Outlook, Gmail, and Apple Mail, plus mobile layouts.
  5. Run a screen-reader pass: Listen to the message and navigate its links and structure.
  6. Fix and retest: Recheck affected clients after changes, then verify URLs and campaign content before deployment.

Use this matrix to track findings rather than relying on memory:

Client / setupCheckExpected resultStatus / notes
Gmail webImage alternativesInformative images have useful alternativesRecord pass/fail and issue
Outlook desktopCTA and reading orderCTA is clear and content order makes senseRecord pass/fail and issue
Mobile email appReadabilityText and links remain usable on a small screenRecord pass/fail and issue
Screen reader setupLinks and structureSpoken content is understandable and navigableRecord setup and findings
Dark mode previewContrastImportant text and controls remain distinguishableRecord client-specific result

Use the email campaign QA checklist for broader campaign checks and the pre-production email testing guide for rendering-focused testing.

Common Accessibility Failures and Fixes

  • Important copy exists only in an image: Put essential information in live text where possible and provide a meaningful alternative for informative images.
  • Decorative images are announced: Use an empty alt="" for images that convey no information.
  • Every CTA says “Click here”: Write distinct link text that describes the destination or action.
  • Layout tables are announced as data: Mark layout-only tables as presentational where appropriate, while preserving semantic data tables.
  • Contrast is checked only in the default theme: Measure actual colors in light mode and preview relevant dark-mode clients.
  • Automated tests are treated as final sign-off: Add manual screen-reader and client testing, and document the scope of testing.

Frequently Asked Questions

Can an HTML email be WCAG compliant?

You can apply relevant WCAG success criteria and test an email against them, but avoid claiming blanket compliance without defining the criteria, clients, and assistive technologies evaluated. Email client behavior varies.

What contrast ratio should email text meet?

WCAG AA generally calls for at least 4.5:1 for normal text and 3:1 for large text. Measure actual colors and check relevant dark-mode previews.

Should every email image have alt text?

Informative images need concise text alternatives that communicate their purpose. Decorative images should generally use an empty alt="" attribute.

Should layout tables use role="presentation"?

Use role="presentation" for tables used only for layout, where appropriate. Keep semantic structure for tables that present real data.

How should I test email accessibility?

Combine markup inspection and contrast checks with manual screen-reader testing in representative email clients and on relevant devices. Verify reading order, image alternatives, links, and headings.

Final Pre-Send Accessibility Checklist

Accessible email work is a repeatable practice, not a single validator result. Make the core message understandable without images, provide useful alternatives, write descriptive links, check contrast, preserve logical reading order, and test the rendered email with assistive technology.

Before you send: Save QA results, document the clients and assistive technologies tested, resolve high-impact issues, and rerun checks after the final content or code changes.

Continue Learning HTML Email Development

Explore related guides on responsive email development, Outlook compatibility, dark mode, and campaign QA.

Back to Blog Get in Touch