Back to reviews and guides

Email Accessibility Checklist: How to Check an Email for Accessibility

A practical, step-by-step email accessibility checklist covering subject lines, plain-text fallback, images, contrast, code, links, forms and client quirks. Includes manual and automated tests, common mistakes and a printable checklist to run before sending.

Email Accessibility Checklist: how to check an email for accessibility

This Email Accessibility Checklist gives editors and developers a step by step list to check before you send. Use it to validate content, images, structure, colours, interactive elements and client behaviour. Every item below is a practical test you can run now.

Why check email accessibility

Accessible email reaches more people. It helps recipients who use screen readers, keyboard navigation, low vision settings, or assistive tech on phones. It also reduces support requests and complies with accessibility standards such as WCAG 2.1 AA and WAI-ARIA expectations for content.

Before you start: quick rules

  • Include a plain-text version. Many assistive tools prefer it.
  • Use semantic structure and logical reading order in the HTML.
  • Place important information in text, not only in images.
  • Test with at least one desktop and one mobile screen reader.

Checklist: content and subject line

Subject line and preheader

  • Keep the subject clear and descriptive. Avoid all-caps and punctuation that reads oddly in speech output.
  • Ensure the preheader adds context and is not repetitive with the subject.

Headings and reading order

  • Use headings to break content for visual scanning and for screen reader navigation. Many email clients remove true heading tags, so use visible heading styles plus a clear DOM order.
  • Confirm the reading order follows visual order. Test by tabbing through and using a screen reader.

Language and plain text

  • Set the email language attribute where your sending platform allows it. This helps screen readers use correct pronunciation.
  • Provide a plain-text alternative. Verify it contains the same essential information and links as the HTML version.

Checklist: images and media

  • Add alt text for meaningful images. Keep alt short but descriptive. If the image is decorative, use empty alt text (alt=“”).
  • Do not rely on background images for essential information. Many clients block them.
  • For complex images such as charts, provide a short summary in the body and a longer description linked or placed below the image.
  • Do not embed text inside images unless you also provide that text in the HTML.

Checklist: colour and contrast

  • Use a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, as specified in WCAG 2.1 AA.
  • Test contrast for text over images and buttons. If contrast fails, increase text size or change colours.
  • Avoid relying on colour alone to convey meaning. Add labels, icons or text markers.
  • Use descriptive link text. Instead of “Click here” write “Download the invoice” or similar.
  • Make buttons accessible. Use a clear focus state and ensure the clickable area is large enough for touch (recommended 44x44 CSS pixels).
  • Verify links work in the plain-text version.

Checklist: code, HTML and CSS

  • Use table-based layout only for structure where necessary. Keep DOM order linear and logical.
  • Use inline CSS for styling. Some clients ignore external stylesheets and head styles.
  • Avoid relying on ARIA as a substitute for semantic structure. Many email clients have limited ARIA support.
  • Do not use role attributes that are not widely supported by clients. When you do use them, test across clients.
  • Avoid position:absolute for critical content. It can break reading order in some clients.

Checklist: attachments and documents

  • Prefer linking to an accessible HTML page rather than attaching documents where possible.
  • If you attach PDFs, make sure they are tagged and tested with a screen reader.

Checklist: forms and tracking

  • If the email contains a form, ensure all form fields have labels. Use visible labels when possible.
  • Give each input a clear associated label in the DOM order.
  • Test any interactive elements with keyboard only navigation.

Testing: automated and manual

Automated checks

  • Run an accessibility scanner on the HTML. Tools such as axe, WAVE or Lighthouse can find many problems quickly.
  • Run a colour contrast checker like Colour Contrast Analyser for text and backgrounds.

Manual checks

  1. Open the plain-text version and verify content, links and order.
  2. Tab through the email to confirm keyboard focus order and visible focus outlines.
  3. Test with at least one desktop screen reader such as NVDA or JAWS, and one mobile screen reader such as VoiceOver or TalkBack.
  4. Listen for logical reading order and clear link text. Check alt text is announced correctly.

Client-specific notes and quick tests

Different mail clients render HTML differently. These quick checks help locate client-specific failures.

Test Gmail (web/mobile) Outlook (Windows) Apple Mail / iOS Mail
Background images Often ignored on some mobile apps May be removed. Use fallbacks Generally supported but test contrast
CSS support Limited: inline CSS is safest Very limited. Outlook uses Word engine Good support for modern CSS
Reading order Verify DOM order and tab sequence Check for odd ordering; test with screen reader Usually matches visual order but test

How to run a focused test sequence (practical step by step)

  1. Send a test to a real account in Gmail and Outlook and open on desktop and a handset.
  2. View the plain-text version and check links and order.
  3. Tab through the message. Note any missing focus indicator or skipped content.
  4. Activate a screen reader: NVDA on Windows, VoiceOver on iOS. Read the email and listen for logical flow.
  5. Run an automated scanner against the HTML and fix issues it finds.

Common mistakes

  • Relying on images for all call to actions. If images are blocked the CTA disappears.
  • Using vague link text like “Learn more” without context in the link or surrounding text.
  • Embedding important text inside background images or decorative-only elements.
  • Assuming ARIA will fix structural problems. ARIA cannot compensate for broken DOM order.

Two things many guides miss

First, test subject lines and preheaders with screen readers. They are the first content a recipient hears. Second, check how your email behaves in dark mode. Colours and images can invert or change. Provide sufficient contrast and avoid placing essential text on images that may become unreadable.

Printable quick checklist

  • Subject and preheader clear
  • Plain-text version included
  • Alt text on meaningful images
  • Contrast meets WCAG 4.5:1 or 3:1 for large text
  • Descriptive link text
  • Logical reading order and heading structure
  • Keyboard focus visible and correct
  • Test with screen readers on desktop and mobile
  • Avoid essential content in background images

Resources and tools

  • Screen readers: NVDA, JAWS, VoiceOver, TalkBack
  • Automated tools: axe, WAVE, Lighthouse
  • Email test platforms: Litmus, Email on Acid
  • Contrast tools: Colour Contrast Analyser and built-in browser devtools

Use this checklist every time you build and approve an email. Run the fast tests first, then fix the high-impact failures. That workflow catches most issues before they reach users.