Email Accessibility Best Practices

Email reaches more people than any other digital channel. It is also one of the most inconsistent rendering environments — hundreds of email clients, each with different HTML and CSS support, different screen reader behavior, and different user settings. Accessible email design must account for this fragmentation while meeting the same WCAG principles that apply to web content.

The Email Accessibility Baseline

Semantic Structure

Email clients vary in HTML support, but basic semantics work universally:

Headings: Use <h1> through <h6> to structure content. Screen reader users navigate emails by headings the same way they navigate web pages.
Paragraphs: Use <p> tags, not <br><br> for paragraph spacing.
Lists: Use <ul> and <ol> for actual lists, not lines of text with bullet characters.
Tables for layout: Email still relies on HTML tables for layout (CSS Grid and Flexbox have limited email client support). Use role="presentation" on layout tables so screen readers do not announce them as data tables.

Language Declaration

Set lang on the <html> element of the email. This lets screen readers switch pronunciation engines for different languages, the same requirement as WCAG SC 3.1.1. See our internationalization guide for multi-language considerations.

Plain Text Alternative

Always include a plain-text version (multipart MIME). Some users prefer plain text, some email clients default to it, and screen reader users may find it easier to navigate. The plain-text version must contain the same content and calls to action as the HTML version.

Images and Alt Text

Every image needs an alt attribute. This is the single most impactful accessibility fix for email.

Informational images: Describe the content. “Photo of the new product in use” — not “image” or “photo.jpg.”
Text-in-images: If an image contains text (a common email design pattern), the alt text must contain that text verbatim. Users with images blocked (a default in many corporate email clients) rely on alt text.
Decorative images: Use alt="" (empty alt). Spacer GIFs, decorative dividers, and background patterns should not be announced.
CTA buttons as images: If your call-to-action button is an image, the alt text must match the button text: alt="Shop the sale".

Color and Contrast

All contrast requirements apply: 4.5:1 for normal text, 3:1 for large text. Email presents additional contrast challenges:

Images-off mode: Many corporate email clients block images by default. If your email is all images, the user sees only alt text on a blank background. Ensure your email is readable with images disabled.
Dark mode rendering: Gmail, Outlook, and Apple Mail apply dark mode transformations that can invert colors, change backgrounds, and alter contrast. Test your email in dark mode across multiple clients.
Link color: Links must be distinguishable from surrounding text by more than color alone (underline is the standard approach).

Links and CTAs

Descriptive link text. “Read the full article” — not “click here” or “learn more.” Screen reader users often navigate by link list; every link must make sense out of context.
Touch-friendly CTA buttons. The same touch target size guidelines apply: minimum 44x44 CSS pixels is recommended for email buttons.
Bulletproof buttons. Use HTML/CSS buttons rather than image buttons. VML-based bulletproof buttons render in Outlook while remaining accessible:

<table role="presentation" cellpadding="0" cellspacing="0">
  <tr>
    <td style="background:#1a73e8; border-radius:4px; padding:12px 24px;">
      <a href="https://example.com" style="color:#ffffff; text-decoration:none; font-weight:bold;">
        Shop the Sale
      </a>
    </td>
  </tr>
</table>

Reading Order and Layout

Because email uses table-based layout, reading order depends on table cell order in the source code. In a two-column layout, cells in the first row read left-to-right before moving to the second row.

Mobile stacking: Use media queries (where supported) to stack columns vertically on small screens. Where media queries are not supported (some Gmail versions), use a single-column layout by default.
Consistent layout: WCAG SC 3.2.3 (Consistent Navigation) applies to email campaigns. If you send regular newsletters, maintain the same section order across issues.

Interactive Email Accessibility

Some email clients support interactive elements (accordions, carousels, forms). These must meet the same accessibility requirements as web components:

Keyboard operability.
ARIA states and roles.
Focus management.

However, support is inconsistent. Always provide a fallback experience for clients that do not support interactive features — typically a static layout linking to a web version.

Testing Email Accessibility

Read the email with images off. Is all essential information available through alt text and live text?
Navigate with a screen reader in your email client. Test in Apple Mail with VoiceOver and in Outlook with NVDA.
Test dark mode in Gmail (web and mobile), Apple Mail, and Outlook.
Validate HTML — malformed HTML causes inconsistent rendering and screen reader issues.
Use Litmus or Email on Acid for cross-client rendering tests, including accessibility checks.

Key Takeaways

Set the lang attribute, use semantic headings and lists, and add role="presentation" to layout tables.
Every image needs alt text — especially text-in-images and CTA buttons.
Test with images off, in dark mode, and with a screen reader.
Use HTML/CSS buttons instead of image buttons for calls to action.
Always provide a plain-text alternative.

Next Steps

Apply color contrast standards to your email design system.
Extend accessibility principles to PDF documents sent as email attachments.
Review the WCAG 2.2 guidelines that underpin email accessibility requirements.

Email accessibility guidance adapted from the Email Markup Consortium (EMC) accessibility guidelines, Litmus accessibility resources, and W3C WAI WCAG 2.2 principles applied to email content.