Accessible email newsletters

An HTML email is a message written in HTML and CSS, like a web page, but opened in a mail client such as Gmail, Apple Mail or Outlook instead of a browser. That changes what can go wrong: you do not control the client. Mailchimp's help page on alt text says many email clients turn images off by default, Litmus's coding guide (which says its information may not be updated) says some clients completely invert colors in dark mode, and a screen reader follows the order of the code, not the layout (see how screen readers read a page). A newsletter that survives all three is built from real text, with markup that says what each part is.

This guide sits inside our guide to how to make a website accessible. It leans on WCAG 1.1.1 Non-text Content for images, 2.4.4 Link Purpose (In Context) for links and 3.1.1 Language of Page for the language.

Does WCAG apply to email?

WCAG was written for web content. W3C's WCAG overview says WCAG can also be applied to non-web information and communications technology, as described in WCAG2ICT, which W3C calls informative: it sets no requirements. Neither page lists email among its examples. HTML email uses the same elements as a web page, so it is GotAlt's reading that WCAG's criteria are the right checklist. Mail clients are not browsers, though, and support different parts of HTML and CSS, so test each rule in the clients your readers use.

Whether a particular law reaches a marketing email is decided by that law's own text, not by WCAG. Our accessibility laws overview and the free Which accessibility laws apply to me? questionnaire are places to start. This page is general information, not legal advice.

Send live text, not a picture of a newsletter

A newsletter exported as one large image gives a screen reader nothing to read, cannot be resized or restyled by the reader, and shows only its alt text when images are blocked. WCAG 1.4.5 Images of Text (Level AA) asks for text rather than images of text, except where the user can customize the image or a particular presentation is essential. Logos count as essential. W3C's reasoning is that people cannot change how text looks inside an image.

Mailchimp's email accessibility tips say important information should always be in actual text, not embedded in graphics. If a banner must be an image, it is GotAlt's reading that its alt text should carry the same words and the offer and link should also appear as live text. See images of text.

Alt text for newsletter images

Alt text is the text in an image's alt attribute. In email it does two jobs: a screen reader reads it in place of the image, and everyone sees it when the client blocks images. WCAG 1.1.1 (Level A) asks for a text alternative that serves the equivalent purpose.

• Informative images. Say what the image adds to the message, in a short phrase or sentence. See our alt text guide, how long alt text should be and, for a shop, alt text for product images.
• Decorative images. Spacers, dividers and tracking pixels get an empty alt attribute, alt="". W3C's Understanding document for 1.1.1 says decorative content should be ignorable by assistive technology, and Litmus warns that if the empty alt attribute is left out, screen readers will read out the image's URL. See decorative images.
• Images that are links. The alt text names the destination or action, not the picture. W3C's example is a linked newspaper thumbnail whose alt text names the page it opens. Mailchimp warns that some email clients do not show alt text for a linked image, so it is GotAlt's reading that a text link beside it is safer.
• Text already nearby. Do not repeat a caption or headline in the alt text. Litmus's example is a product photo whose alt text only repeats the product name, which leaves a screen reader repeating it.

<a href="https://example.com/spring-sale/">
  <img src="spring-sale.png" width="600" alt="Spring sale: shop the sale">
</a>
<img src="divider.png" width="600" height="2" alt="">

Headings, paragraphs and layout tables

WCAG 1.3.1 Info and Relationships asks that structure conveyed by appearance also be available in the code. W3C's example is that sighted users often recognize a heading by its larger, bold font. In email that means:

• Real headings, paragraphs and lists. Use h1 to h6 for headings, p for paragraphs and ul or ol for lists, with heading levels in order. The Email Markup Consortium's 2026 accessibility report advises wrapping the main title in an h1, and notes that a short email may not need one. The consortium describes itself as an independent not-for-profit community group. See heading structure.
• Layout tables marked as layout. A layout table is a table used to position content, not to present data. The same report says it is better to avoid table layouts, and that if you use them you should set role="presentation" or role="none" on the table. MDN explains the effect: the table, rows and cells stop being exposed to assistive technology, but content inside the cells, including nested tables, still is. So every layout table needs the role. Real data tables stay data tables (see accessible data tables).

<table role="presentation" width="600">
  <tr>
    <td>
      <h1>October news from the shop</h1>
      <p>The main message goes first.</p>
    </td>
  </tr>
</table>

Reading order follows the code. WCAG 1.3.2 Meaningful Sequence (Level A) asks that, where order affects meaning, a correct reading sequence can be programmatically determined, and lists a layout table that does not make sense when read in order as a failure. Put the main message first in the code; Mailchimp's tips recommend single-column layouts.

Language and title

Success criterion 3.1.1 (Level A) asks that a page's default human language can be programmatically determined, and W3C explains that screen readers use it to load the correct pronunciation rules. In HTML that is the lang attribute on the html element (see the lang attribute).

Email needs one more step. The Email Markup Consortium's report says a number of email clients remove the language setting from the html element, so it recommends also setting lang, and dir (the text direction), on the direct children of the body. Its fallback for an unknown language is lang="und", which it calls much better than nothing. It also recommends a short, descriptive title for the email, like its subject line.

<html lang="en" dir="ltr">
<head>
  <title>October news from the shop</title>
</head>
<body>
  <div lang="en" dir="ltr">...</div>
</body>

Color, contrast and dark mode

WCAG 1.4.3 Contrast (Minimum) (Level AA) asks for a contrast ratio of at least 4.5:1 for text and 3:1 for large text, which it defines as at least 18 point, or 14 point bold. It applies to images of text too. Check the places where pale colors are easy to miss: footer text, the unsubscribe link, text over a photo and button labels. Check each pair with the free contrast checker and, for text over a picture, the image contrast checker. Our color contrast guide has more.

Mailchimp's tips also say not to rely on color alone, so give links more than a color change (see use of color for links).

Dark mode is another place where email differs from a website. Litmus says some clients leave an email as it is, some completely invert its colors and some only partly do. The prefers-color-scheme media query is one way to control the result, but Can I Email's support data lists clients including AOL and the desktop webmail version of Yahoo! Mail as not supporting it (its page says it was last tested on March 8, 2023). Send a test to a client in dark mode and read the whole email again, logos and transparent images included. See dark mode accessibility for the ratios.

Links and buttons

Mailchimp's tips note that screen readers can build a list of every link in an email, so each link should make sense on its own. W3C's Understanding document for 2.4.4 says text in the same paragraph, list item or table cell can supply a link's purpose, yet it is a best practice for different destinations to have different link text. Five "Read more" links under five stories leave the person who browses the list guessing, so name the story. The Email Markup Consortium's report also flags links with no discernible text: give a link visible text, and a linked image alt text. See accessible link text.

For buttons, it is GotAlt's reading that live text with padding is safer than a button image, because the label survives blocked images. WCAG 2.5.8 Target Size (Minimum) (Level AA) asks for pointer targets of at least 24 by 24 CSS pixels, with exceptions that include a link inside a sentence (see touch target size).

Emoji, animation and video

Emoji and symbols. Litmus's 2020 guide to screen readers, which says its information may not be updated, says subject lines cannot use ARIA, so emoji in them are read out as they are. Keep meaning in words. In the body, it suggests hiding decorative arrows and bullets with aria-hidden="true".

Animated GIFs and video. WCAG 2.2.2 Pause, Stop, Hide (Level A) requires a way to pause, stop or hide moving content that starts automatically, lasts more than five seconds and sits beside other content. Its Understanding page lists a technique for GIFs: stop them after a number of cycles within five seconds. In email, it is GotAlt's reading that the dependable route is a GIF that stops by itself within five seconds, not one that relies on a pause control the reader's client may not support (see animation and reduced motion). For video, it is GotAlt's reading that a link to a captioned video on a web page is safer than embedding one (see video captions and transcripts).

Plain-text and web versions

Mailchimp's accessibility help article says it automatically generates a plain-text version of an HTML campaign for contacts who prefer one, and that plain-text emails have no images, rich-text formatting or embedded links. Read yours before you send: it should carry the same message, with any link you need written out as a web address. A web version, the "view in browser" page, gives readers a second way in and lets you run page tools on the email, but only if that page is accessible too.

Newsletter accessibility checklist

Run down this list before each send. Passing it is not a certification of anything: it covers what a person can check in a few minutes.

Check it yourself

Four tests need a person and a test send:

1. Images off. Block images in your mail client, or send a test to an account that does. Each image should give way to alt text that carries its message, with the offer and link still readable.
2. Keyboard. Mailchimp's tips advise reading through the email with only the keyboard. The Email Markup Consortium's compliant standards expect keyboard focus to be visible inside the email at all times, so do not remove focus styles.
3. Screen reader. Listen to the email in a screen reader such as VoiceOver or NVDA. Open the headings list and the links list, then read the message in order. Our guide to how screen readers read a page explains those lists.
4. Dark mode and zoom. View the email in a client in dark mode, then zoom in and see whether the text still fits (see zoom and reflow).

Then use the free tools. The link text checker accepts pasted HTML, which never leaves your browser, so paste your email's source: it lists every link with the name a screen reader announces and flags empty links, vague phrases, bare web addresses and repeated text that goes to different places. The contrast checker takes two colors, so run your body text, footer, button label and dark mode colors through it. The alt text checker reads a page address, not an inbox, so use it on your newsletter's web version if that sits at a public address. It downloads up to six images and judges whether each alt text is true of its image. Scan my site for free checks pages of your website, such as your sign-up page and web archive.

None of these opens your email in Gmail or Outlook, and, as the Email Markup Consortium's report notes, automated tools cannot evaluate intent: a checker can confirm that an alt attribute exists, not that its text suits the image. Rendering in each client is for your test sends.