What this is for#
Roughly 15% of your subscribers have a permanent or situational disability that affects how they read email. Some are screen-reader users. Some are low-vision readers who zoom to 200%+. Some are color-blind (8% of men globally). Some have motor impairments that affect mouse precision. Some are dyslexic and depend on font + line-spacing choices for readability. Some are temporarily impaired — reading on a phone in bright sunlight, or in a moving car, or while exhausted.
The European Accessibility Act took effect 2025-06-28 and applies to "digital services for consumers" including marketing emails. The US ADA has been interpreted by courts to cover digital channels since 2017 — and the Department of Justice's 2024 NPRM strengthens that interpretation. Enforcement is ramping. Fines reach €100,000+ in the EU, with private litigation in the US adding settlement risk.
Beyond compliance, accessible email performs better for everyone — ~10-25% better engagement across all readers, not just those with disabilities. Larger text is easier to scan on phones. Higher contrast is easier to read in any lighting. Semantic structure is easier to navigate even with full sight.
This guide is the operator-grade reference for the seven structural rules that make bulk email accessible — built around WCAG 2.2 AA criteria that actually translate to the constrained email medium.
Why email accessibility is different from web accessibility#
Web pages can ship full ARIA semantics, JavaScript focus management, CSS variables for theming, and modern CSS for layout. Email cannot. Major email clients strip:
- JavaScript entirely (and have for 20+ years)
- Most modern CSS (Outlook desktop in particular — uses Word's rendering engine, supports ~30% of modern CSS)
- Web fonts (Outlook ignores; iOS Mail loads from font CDN; Gmail strips on Android)
- Custom HTML elements (most clients strip non-standard tags)
- <style> blocks (Gmail strips when forwarding; many clients ignore media queries)
- External resources (Yahoo blocks image loads by default; most clients strip linked CSS)
The accessibility techniques that work on the web — <button> with aria-label, focus-trap modals, dynamically-updated aria-live regions — don't translate. Email accessibility is mostly structural HTML + inline styles + careful color choice + alt text discipline.
The good news: that's a much smaller surface area to master. Seven structural rules cover ~95% of WCAG AA compliance for email.
The seven structural rules#
1. Use semantic HTML — real headings, real lists, real paragraphs#
Screen readers navigate email by structure. A user who hits the "next heading" key on their screen reader jumps to the next <h1>, <h2>, <h3> etc. If your email is all <div style="font-size: 24px; font-weight: bold"> instead of <h2>, the screen reader can't navigate it — and visually-able users get no semantic benefit either.
Use:
<h1>Welcome to AcelleMail</h1>
<p>Thanks for signing up. Here's what to do next.</p>
<h2>Step 1: Verify your email</h2>
<p>Click the button below to verify…</p>
<h2>Step 2: Choose your plan</h2>
<ul>
<li>Starter — for solo creators</li>
<li>Business — for growing teams</li>
<li>Enterprise — for high-volume operators</li>
</ul>
Avoid:
<!-- Don't fake headings with divs -->
<div style="font-size: 32px; font-weight: bold;">Welcome to AcelleMail</div>
<!-- Don't fake lists with line breaks -->
<div>• Starter — for solo creators</div>
<div>• Business — for growing teams</div>
Visually identical; structurally invisible to assistive tech.
Use <h1> once per email (the main heading). Then <h2> for major sections, <h3> for sub-sections, and so on. Skip levels only with intention.
2. Use real text, not images-of-text#
Images-of-text fail multiple ways:
- Screen readers ignore them (unless
alt is set, and even then, alt is summary-quality not full-text-quality).
- Search-in-email fails (users can't Ctrl-F to find the offer).
- Zoom degrades quality (low-vision users at 200%+ see pixelated text).
- Email clients block images by default (Yahoo, Outlook desktop). If the message is image-only, recipients see nothing.
- Dark-mode inversion breaks images (text-on-image-background can become unreadable when client auto-inverts).
The safest rule: all primary content as HTML text. Use images for product photos, illustrations, and decorative elements only. Brand fonts can be approximated with system fonts (Arial/Helvetica/Georgia) or fallbacks — see Email Template Design Best Practices.
3. Alt text on every image — descriptive, not redundant#
<!-- Product image with descriptive alt -->
<img src="..." alt="Black leather backpack, 25L capacity, with laptop sleeve">
<!-- Logo with brand name (not "logo") -->
<img src="..." alt="AcelleMail">
<!-- Decorative image — empty alt is correct -->
<img src="..." alt="" role="presentation">
Three principles:
- Functional images (logos, CTA-button images) → describe the function/destination, not the visual ("AcelleMail" not "AcelleMail logo image").
- Content images (product photos, illustrations supporting the message) → describe the content concisely.
- Decorative images (dividers, background flourishes, spacers) →
alt="" and role="presentation". Empty alt is correct; missing alt is wrong.
Avoid alt text that says "image of" or "picture of" — screen readers already announce "image."
4. Color contrast at WCAG 2.2 AA — 4.5:1 for text, 3:1 for large#
WCAG 2.2 AA requires:
- 4.5:1 contrast ratio for normal text (under 18pt regular or 14pt bold)
- 3:1 contrast ratio for large text (18pt+ regular or 14pt+ bold)
- 3:1 contrast ratio for UI components and graphical objects (CTA buttons, icons)
Check your colors at webaim.org/resources/contrastchecker. For brand colors that fail:
- Slightly darken or lighten the text or background to push to compliance.
- Use color as a secondary signal only — never the only way information is conveyed.
Common email-design fails:
- Light gray body text on white background.
#aaaaaa on #ffffff is only 2.85:1 — fails AA.
- Brand-colored CTA button text that's hard to read at small sizes.
- Light-on-light gradients in headers.
Fix the text colors. The hierarchy by contrast usually looks like:
- Headings:
#000000 or #111111 on white = ~20:1 (overkill but safe)
- Body text:
#333333 on white = 12.6:1 (very accessible)
- Secondary text:
#666666 on white = 5.7:1 (passes AA)
- Minimum:
#767676 on white = exactly 4.54:1 (just passes AA — risky)
- Don't use anything lighter than
#767676 for text on white background.
5. Body text 16px or larger#
WCAG doesn't mandate a specific size, but reality does:
- Mobile screens are small; most readers can't easily zoom.
- Older adults (the most active email reader cohort) lose ~1pt of comfortable reading size per decade of age past 40.
- Outlook on Windows can render small text crisply but blurs at <16px on high-DPI displays.
Use 16px minimum for body text, 18-20px preferred. Headings scale up from there:
<h1> — 28-32px<h2> — 22-26px<h3> — 18-20px- Body — 16-20px
- Secondary text (footer, fine print) — 14px minimum
<p style="font-size: 18px; line-height: 1.5; color: #333;">
Body text at 18px with 1.5 line-height — comfortable on any device.
</p>
Line height matters as much as font size. 1.5× line height (a.k.a. line-height: 1.5) is WCAG-recommended for body text.
6. Dark-mode-aware color choices#
Gmail, Apple Mail, Outlook for iOS, and now Outlook on Windows 11 auto-invert email colors to fit a user's dark-mode setting. Sometimes the inversion is helpful; often it's broken.
Common dark-mode failures:
- Logo with transparent background on white → inverted to white logo on dark, but if the logo has light gray accents, they vanish.
- CTA button: white text on brand color → most clients keep button colors stable but the visual context around shifts dark, making the button look out of place.
- Dark text on white card on dark background (deliberate light-card-in-dark-mode) → client inverts the card AGAIN, making text black-on-black.
- Images with hardcoded white backgrounds → look like islands of light against dark backgrounds.
Defenses:
- Use
prefers-color-scheme media query for clients that respect it (Apple Mail, Outlook macOS):
<style>
@media (prefers-color-scheme: dark) {
.light-only-bg { background-color: #1a1a1a !important; }
.light-only-text { color: #e0e0e0 !important; }
}
</style>
- Set images with transparent backgrounds when possible (PNG with alpha). Adds a
meta to disable Gmail's auto-darkening:
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
- Test in dark mode before shipping. iOS Mail dark mode is the easiest test surface (Settings → Display → Dark).
For more on dark-mode specifics, see Dark Mode Email Design.
7. Functional, accessible CTAs#
The most common accessibility failure in marketing email is the CTA button. Three rules:
Make the link/button focusable and announce intent. Use real <a> elements, not <div onclick>. The link text should describe the destination — "Read the case study" not "Click here."
<!-- Good — screen reader announces "Read the case study, link" -->
<a href="https://..." style="
display: inline-block;
padding: 16px 32px;
font-size: 18px;
background-color: #1e40af;
color: #ffffff;
text-decoration: none;
border-radius: 6px;
">
Read the case study
</a>
<!-- Bad — screen reader announces "Click here, link" with no context -->
<a href="https://...">Click here</a>
Buttons need 44×44px minimum touch target. WCAG 2.5.5 (Target Size). Mobile readers with motor impairments or in non-ideal conditions (gloves, jolting transit) need at least 44px square to tap reliably. Most email CTAs need padding to hit this — padding: 16px 32px gets you there with normal text.
Color is a secondary signal. Underline links by default (don't disable underlines on <a> in email body text — most clients show them by default). For buttons, the button shape + bold weight + label clarity all carry meaning beyond color, so a color-blind user still knows it's actionable.
For Outlook-specific button rendering (the hardest client), see Bulletproof CTA Buttons for Outlook.
Inline-style techniques that email clients allow#
CSS-in-<style> is risky (Gmail strips on forward; older clients ignore). Inline CSS via style="" attribute is the safe bet. Three patterns that improve accessibility AND survive client stripping:
A. Inline font-size + line-height on every text element#
<p style="margin: 0 0 16px 0; font-size: 18px; line-height: 1.5; color: #333333;">
Lorem ipsum…
</p>
This guarantees the size renders identically across clients. Many clients (notably Outlook desktop) ignore <style> block declarations but respect inline.
B. Inline padding for tap targets#
<table cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="padding: 16px 0;">
<a href="..." style="display: inline-block; padding: 14px 28px; font-size: 18px; …">
Read more
</a>
</td>
</tr>
</table>
The outer <td> padding adds breathing room around the button. The inner <a> padding makes the link itself a large tap target.
C. Inline color with !important for dark-mode protection#
For clients that auto-invert (Gmail), !important can keep your colors:
<p style="color: #333333 !important; background-color: #ffffff !important;">
Body text…
</p>
This is heavy-handed; use sparingly. Generally let dark-mode happen and design for it (rule 6), rather than blocking it everywhere.
The 5-minute accessibility audit#
Before sending any campaign, run this checklist:
| Check |
How |
| Headings have semantic levels |
Open the source. Search for <h1>, <h2>, etc. There should be at least one of each, in nested order |
| Every image has alt text |
Search source for <img. Every match should be followed by alt="..." (descriptive) or alt="" (decorative) — never missing |
| Body text >= 16px |
Search for font-size: 14, font-size: 12, font-size: 10 — these should only appear in footer/legal text |
| Color contrast passes 4.5:1 |
Paste foreground + background hex into webaim.org/resources/contrastchecker for the body text and the CTA button |
CTAs use real <a> with descriptive text |
Search for "Click here" — none should exist |
| CTAs have 44×44px tap target |
Open the email on a phone. Tap each link with your knuckle (less precise than fingertip). All should work |
| Dark mode test |
iOS: Settings → Display → Dark. Open the email in iOS Mail. Look for white-card flashes and broken contrast |
| Screen reader spot check |
macOS: Cmd+F5 to enable VoiceOver. Read the email aloud. Note where it sounds confusing — fix those parts |
The full audit takes 5 minutes per email template after the first time. After you've internalized the seven rules, you stop creating accessibility bugs in the first place.
WCAG 2.2 AA criteria that map to email#
Not all WCAG criteria translate to email (no focus management, no live regions, no skip-links). The ones that do:
| WCAG 2.2 criterion |
Means in email |
| 1.1.1 Non-text content (A) |
Every image has alt text |
| 1.3.1 Info and relationships (A) |
Use real headings, lists, tables (not faked with <div>) |
| 1.3.5 Identify input purpose (AA) |
If using preference center, autocomplete attributes on inputs |
| 1.4.3 Contrast (minimum) (AA) |
4.5:1 text contrast |
| 1.4.4 Resize text (AA) |
Text remains usable at 200% zoom; use relative sizes when possible |
| 1.4.10 Reflow (AA) |
Single-column on mobile (320px) without horizontal scroll |
| 1.4.11 Non-text contrast (AA) |
3:1 for CTA buttons + icons |
| 1.4.12 Text spacing (AA) |
User-overridable spacing: don't lock line-height too tight |
| 2.4.4 Link purpose (in context) (A) |
Link text describes destination ("Read the case study" not "Read more") |
| 2.5.5 Target size (AAA, but de-facto AA for mobile) |
44×44 px CTA targets |
| 3.1.1 Language of page (A) |
<html lang="en"> (or appropriate code) at top of email HTML |
| 4.1.2 Name, role, value (A) |
Use real <a> and <button>, not <div onclick> |
Hitting AA on the above 12 covers most legal exposure. The remaining WCAG criteria are largely web-platform features that don't apply to email.
Regulatory landscape (as of 2026-05)#
European Accessibility Act (EAA). Took effect 2025-06-28. Applies to "digital services for consumers" — explicitly includes marketing emails sent to EU consumers, regardless of where the sender is based. Fines up to €100,000 per violation in most member states; some go higher. Member-state implementation varies, but enforcement bodies are real and litigation is starting.
US ADA. Title III of the ADA has been interpreted by federal courts to cover digital content since the 9th Circuit's 2017 ruling (Robles v Domino's). The DOJ's 2024 NPRM strengthens this. Private-litigation risk is the main driver — class-action suits over inaccessible commercial content settle for $20k-$500k typically.
Section 508. Applies if you send email to or on behalf of US federal agencies. Mandatory AA conformance.
State laws. California, New York, and several others have layered additional digital accessibility requirements. California's Unruh Civil Rights Act has been the most-litigated.
The practical operator response: comply with WCAG 2.2 AA across all consumer-facing email, regardless of where recipients are. The compliance cost is small (a one-time template audit + ongoing discipline); the litigation risk is real.
Tools for ongoing testing#
- WAVE Email Accessibility tool — paste your email HTML, get a structured audit report. Free.
- axe DevTools browser extension — runs WCAG checks on any rendered page (including the AcelleMail "Preview as HTML" view of a sent message). Free tier.
- Litmus — paid, but covers accessibility checks alongside email-client rendering tests. ~$99-199/month.
- VoiceOver (macOS) / NVDA (Windows free) / TalkBack (Android) — actual screen-reader tools for hands-on testing.
- iOS Accessibility Inspector (Xcode) — for iOS Mail audit.
Free combination that covers most needs: WAVE + axe + VoiceOver. The paid tools add scale (testing many templates) and email-client-specific rendering depth.
Common myths to ignore#
"Accessible email looks ugly." False. Most-engaged senders (Apple's marketing, Google's, government / nonprofit) ship accessible-by-design templates that look excellent. Constraint forces clarity.
"I only need to care if I have disabled subscribers." False. (a) You don't know who's disabled; assume some are. (b) Situational disability — bright sun, moving train, tired eyes — affects everyone. (c) Legal frameworks don't ask whether your specific recipients are disabled; they ask whether your content is accessible.
"My platform handles accessibility for me." Partially true at best. Platforms ship default templates that are mostly accessible. But the moment you customize colors, fonts, images, or HTML, you're on your own. The audit is on you.
"Image-only emails are fine if I have alt text." False. Yahoo, Outlook, and many corporate clients block images by default. An image-only email with alt text shows the recipient... just the alt text, in a tiny gray box. Use real text for content.
"WCAG is for websites, not email." Increasingly false. EAA explicitly covers email. US case law and DOJ NPRM are moving in the same direction. Treat email like web for compliance purposes.
Related reading#
