Email Accessibility: A Developer's Checklist for Inclusive Transactional Emails

Roughly 15% of the world's population lives with some form of disability. That's over a billion people — and a meaningful chunk of your users are reading transactional emails with screen readers, magnified displays, or high-contrast settings.

Accessible email isn't charity. It's engineering discipline. If a user can't read your password reset email because the contrast is 2:1 or the CTA says "Click here," you've built a broken product.

15%

Global population with a disability

WHO estimate — visual, motor, cognitive, auditory

4.5:1

WCAG AA contrast minimum

For body text under 18px / 14px bold

~80%

Email opened on mobile

Where small text and low contrast hit hardest

Who you're actually designing for

"Accessibility" isn't just screen readers. Transactional emails need to work for:

Blind and low-vision users: screen readers (VoiceOver, NVDA, JAWS), magnification, high-contrast mode
Color-blind users: ~8% of men — red/green deficiency means your error states may be invisible
Cognitive disabilities: dyslexia, ADHD, processing disorders — walls of text and ambiguous CTAs are hostile
Motor impairments: small tap targets are unusable for users with tremors or limited dexterity
Temporary impairments: broken arm, migraine, bright sunlight on a phone screen — this is everyone, eventually

Key takeaway

Accessible email is not a separate feature. It's a constraint that makes every email better for every user — larger tap targets, clearer copy, better contrast. The "accessible" version is just the good version.

Semantic HTML in email: the table problem

Email HTML is stuck in a time warp. Outlook still uses Word's rendering engine. Gmail strips most semantic tags. You can't just write clean HTML5 and call it done.

The pragmatic approach

Use <table role="presentation"> for layout tables — this tells screen readers to ignore the table structure and read content linearly
Use real <h1> through <h3> for headings — most email clients preserve these, and screen readers use them for navigation
Use <p> tags for paragraphs, not bare <br> chains
Set lang on the <html> tag — screen readers use it for pronunciation

Layout table with role=presentation

<table role="presentation" cellpadding="0" cellspacing="0" width="100%">
  <tr>
    <td style="padding: 24px;">
      <h1 style="font-size: 22px; margin: 0;">Your invoice is ready</h1>
      <p style="font-size: 16px; line-height: 1.5; color: #374151;">
        Here's your receipt for the February payment.
      </p>
    </td>
  </tr>
</table>

Without role="presentation", screen readers announce layout tables as data tables — "table with 3 rows and 2 columns" — which is confusing when the table is just holding a logo and some text.

Alt text for images: the decision framework

Every <img> needs an alt attribute. But not every image needs descriptive alt text.

Descriptive alt text

Product logo in the header: alt="Acme logo"
Chart or diagram that conveys data
Hero image that adds context to the message
Icons used as the only indicator of status (✓ / ✗)

Empty alt (alt="")

Decorative dividers and spacer images
Background patterns or gradients
Icons next to text that already says the same thing
Tracking pixels (1x1 images) — always alt=""

Never skip the alt attribute entirely. An omitted alt causes screen readers to read the image filename — usually something like img_20240301_header_v3_final.png.

Color contrast: the numbers that matter

WCAG AA requires a 4.5:1 contrast ratio for normal text and 3:1 for large text (18px+ or 14px+ bold). This isn't optional — it's the difference between readable and unusable.

Common failures in transactional email

Light gray body text on white: #999 on #fff is 2.8:1 — fails AA. Use #595959 or darker
White text on colored CTA buttons: that trendy light blue button? Check it. #60A5FA on white is only 2.4:1
Muted "secondary" text: timestamps, footer links, fine print — these still need 4.5:1

Safe text color pairings

/* Body text — passes AA on white */
color: #374151; /* gray-700: 10.3:1 on #fff */
color: #4B5563; /* gray-600: 7.0:1 on #fff */
color: #6B7280; /* gray-500: 4.6:1 on #fff — just barely */

/* Danger zone — fails AA on white */
color: #9CA3AF; /* gray-400: 3.0:1 — fails for body text */
color: #D1D5DB; /* gray-300: 1.8:1 — never use for text */

Use the WebAIM Contrast Checker to verify your palette. Paste your foreground/background hex values — it takes 5 seconds.

Font sizes: stop shipping 12px body text

Mobile email clients don't always respect your font sizes, but when they do, undersized text is a readability disaster.

Body text: 14px minimum, 16px preferred

At 14px, you're at the floor. At 16px, most users can read comfortably without zooming. If your email is critical (password reset, payment alert), favor 16px.

Headings: 22px+ for primary, 18px+ for secondary

Heading size creates hierarchy. If your heading is 14px and your body is 14px, screen readers can navigate by heading level — but sighted users can't tell the difference.

Line height: 1.5 for body, 1.3 for headings

Tight line height is the #1 reason otherwise-accessible email feels hard to read. Give text room to breathe.

CTA buttons: big, descriptive, unmistakable

Transactional email buttons have two accessibility requirements: they need to be large enough to tap and clear enough to understand out of context.

Accessible CTAs

"Reset your password" — specific action
"Download invoice #1234" — clear outcome
"Verify your email address" — states the task
Minimum 44x44px touch target (Apple HIG)
14px+ button text with sufficient padding

Inaccessible CTAs

"Click here" — meaningless without context
"Continue" — continue what?
"Go" — go where?
Small 28px-tall buttons on mobile
Link text that relies on surrounding color to look clickable

Screen readers often navigate by links. A user tabbing through your email will hear "link: Click here, link: Click here, link: Click here" — which tells them nothing.

Accessible CTA button with inline styles

<a href="https://app.acme.com/reset?token=abc"
   style="display: inline-block;
          padding: 14px 28px;
          font-size: 16px;
          font-weight: 600;
          color: #ffffff;
          background-color: #1D4ED8;
          text-decoration: none;
          border-radius: 6px;"
   target="_blank">
  Reset your password
</a>

Dark mode: accessibility implications

Most email clients now support dark mode, and many users with light sensitivity or low vision rely on it. But dark mode can break your accessibility if you're not careful.

Test contrast in both modes: text that passes AA on white may fail on a dark background if the client inverts colors poorly
Avoid transparent PNGs with dark text: on a dark background, dark text on a transparent image becomes invisible
Use @media (prefers-color-scheme: dark): Apple Mail, Outlook.com, and some Gmail clients support it — provide explicit dark mode styles rather than relying on auto-inversion
Set background colors explicitly: don't assume white. If you don't declare a background, the client picks one — and your carefully tuned contrast ratio becomes unpredictable

The worst dark mode bug: a logo on a transparent background that disappears entirely. Always export logos with a solid background or add a white padding layer.

Testing: tools that catch real problems

You can't manually check accessibility across 90+ email clients. Use tools that automate the painful parts.

Litmus — previews across clients + has an accessibility check feature that flags missing alt text, low contrast, and missing lang attributes
Email on Acid — similar client previews + accessibility audit with WCAG scoring
VoiceOver (macOS) / NVDA (Windows): open your email in Apple Mail or a browser and tab through it. If the reading order makes sense and CTAs are descriptive, you're in good shape
WebAIM Contrast Checker — manual but fast. Paste hex values, get a pass/fail

Key takeaway

Test with a real screen reader at least once per template. Automated tools catch structural issues (missing alt, low contrast), but they can't tell you whether the reading order makes sense or whether your CTA text is meaningful in isolation.

The checklist (copy/paste into your PR template)

Structure

lang attribute set on <html>
Layout tables use role="presentation"
Real heading tags for headings (not bold paragraphs)
Logical reading order when CSS is disabled

Images

Every <img> has an alt attribute
Decorative images use alt=""
Logos and meaningful images have descriptive alt text
No critical information conveyed only through images

Color and typography

Body text contrast ratio: 4.5:1 minimum
Large text contrast ratio: 3:1 minimum
Information not conveyed by color alone (add icons or text labels)
Body font size: 14px minimum (16px preferred)
Line height: 1.5 for body text

Interactive elements

CTA buttons: 44x44px minimum touch target
Button/link text is descriptive without surrounding context
No "Click here" or "Learn more" as standalone link text
Links are visually distinguishable (not just by color)

Dark mode

Background colors explicitly set (not relying on defaults)
Logos tested on dark backgrounds
Contrast verified in both light and dark modes

Email accessibility isn't a separate workstream. It's a handful of constraints baked into your templates from day one. Add role="presentation" to layout tables, check your contrast ratios, write descriptive CTA text, and test with a screen reader once. That's 90% of the work — and it makes your emails better for everyone.