Back to reviews and guides

Email Accessibility Best Practices: How to Design More Accessible Emails

This article lists practical email accessibility best practices: structure, contrast, alt text, plain-text alternatives, keyboard access, testing and client pitfalls. It includes a step-by-step QA checklist and a decision framework for using background versus foreground images.

Email accessibility best practices help more people read and act on your messages. Use clear structure, good contrast, meaningful alt text and tested templates so screen reader and keyboard users can use your emails.

Email accessibility best practices: quick checklist

  • Use a logical reading order with semantic markup and heading-like structure.
  • Provide a plain-text alternative and clear preheader text.
  • Write concise alt text for meaningful images and mark decorative images as decorative.
  • Ensure text contrast meets WCAG 2.1 AA: 4.5:1 for normal text, 3:1 for large text.
  • Make links and CTAs keyboard focusable and clear, with accessible name and purpose.
  • Avoid using images for essential text. If you must, include a real text alternative.
  • Test with at least one screen reader and one keyboard-only pass across major mail clients.

Why follow email accessibility best practices?

Accessible email reaches more of your audience. It reduces support queries. It may help meet legal requirements in some countries. It also improves deliverability when messages are well formed and include a plain-text part.

Structure and semantic order

Emails lack a single standard for headings. Still, you can create a clear reading order. Place the content in a single column for linear reading. Put the most important message first. Use clear visual markers for sections and short paragraphs.

Accessible headings and landmarks

HTML email clients treat headings inconsistently, but you can give structure. Use visually styled headings. For screen readers, ensure the reading order in the HTML source matches the visual order. When possible, include a short top-line summary that doubles as an accessible title.

Text, contrast and legibility

Pick font sizes and line height that stay readable on mobile. Use at least 14px for body text where possible. Keep line height at least 1.4. For contrast follow WCAG 2.1 AA: 4.5:1 for normal body text and 3:1 for large text.

Colour and dark mode

Test emails in dark mode. Some mail apps invert colours or change backgrounds. Avoid using colour alone to convey meaning. Provide clear borders or labels when colour is functional.

Images and alt text

Images must have meaningful alt text or be explicitly decorative. Screen readers read the alt attribute. If an image contains important text, include the same text in the HTML as real text, not just inside the image.

How to write alt text

  • Good alt text: describe the image purpose. Example: “Photo of Dr Maya Patel smiling during a vaccine clinic”.
  • Poor alt text: generic words or repeating the file name. Example: “IMG_1234” or “image”.
  • Decorative images: use an empty alt attribute so screen readers skip them. Example: alt=“”.

Use descriptive link text that explains the purpose. Avoid “Click here”. Make call to action readable when taken out of context. Include the destination in the accessible name if it helps, for example the offer or the expected page.

Keyboard and focus

Ensure links and form controls are reachable with Tab. Keep focus order logical. Provide visible focus styles so keyboard users can see where they are. Inline styles help because some email clients strip global CSS.

Buttons and interactive elements

Buttons in email are usually links styled to look like buttons. Make sure the link has an accessible name. For complex interactivity, prefer progressive enhancement and include a non-JavaScript fallback. Remember most email clients do not run JavaScript.

Tables and layout

Many emails use tables for layout. Use them carefully. Keep table structure simple. Avoid nested tables where possible. Do not use tables to hide content from assistive tech. If you use tables for true tabular data, include a brief caption in the surrounding text to explain the table.

Forms inside emails

Interactive forms often fail in clients. If you include form-like content, provide a clear link to a web page with an accessible form. If you must include form fields, label each field clearly and provide a fallback option.

Plain-text alternative and preheader

Always include a well-formed plain-text version. Screen readers and some assistive tech prefer it. The plain-text version should preserve order and include CTA URLs. Use a short preheader that summarises the main action.

Common mail-client pitfalls

  • Outlook desktop may not support background images the same way as web clients.
  • Gmail and Outlook.com often strip styles from the head. Inline styles are more reliable.
  • Dark mode can invert colours and reduce contrast. Test important visuals.

Testing: what to test and how

Testing needs three parts: automated checks, manual keyboard testing, and at least one screen reader pass. Use a mix of mail clients on mobile and desktop.

Tools and readers to use

  • Screen readers: NVDA on Windows, VoiceOver on macOS and iOS, TalkBack on Android.
  • Automated checks: Accessibility Insights, WAVE, or an email-specific accessibility lint tool.
  • Visual tests: check in Gmail, Apple Mail, Outlook desktop, Outlook web, and major mobile apps.

Step-by-step accessibility QA for one email (practical)

  1. Start with a semantic HTML source and single-column layout.
  2. Create a plain-text version that preserves order and links.
  3. Write meaningful alt text for images. Mark decorative images empty.
  4. Inline essential styles for fonts, colours, and focus indicators.
  5. Run automated checks for contrast and missing alt attributes.
  6. Open the email in at least three clients and one mobile app.
  7. Do a keyboard-only pass: tab through links, check visible focus, read link text aloud.
  8. Do a screen reader pass with NVDA or VoiceOver and note confusing reads.
  9. Fix issues, then re-test the plain-text and HTML versions.

Decision framework: background image or foreground image?

Choose a foreground image when the image conveys essential content. Foreground images can carry alt text and have text alternatives. Use a background image only for purely decorative purposes. If you must use a background image, provide a strong background colour fallback and a real text alternative in the HTML so the content is never lost.

Two accessibility mistakes to avoid

  • Using images for critical text without a text alternative. That breaks both accessibility and searchability.
  • Relying solely on colour to convey meaning. Always pair colour with a label or icon that has an accessible name.

Accessibility governance and workflow tips

Include accessibility checks in your content brief. Add a single checklist item to your release workflow. Keep a test matrix of mail clients and a regression test with a sample email for each campaign. Train writers on alt text and clear CTA writing.

Resources and standards

Match your work to WCAG 2.1 AA for contrast and text accessibility. Use WAI-ARIA to provide roles and states for complex components where supported. Refer to client documentation for Outlook and Gmail quirks when implementing advanced CSS.

Follow these email accessibility best practices regularly. Small changes to structure, alt text and testing will make your campaigns usable by far more people.