The customer support ticket was puzzling at first. "I can't use your emails." The user explained they were blind and used a screen reader. The company's beautifully designed emails were a wall of "image image image link link link"—no alt text, no semantic structure, no way to understand the content.
Email accessibility isn't optional. Beyond the ethical imperative to include everyone, there are legal requirements in many jurisdictions. And practically, accessible emails are better emails—clearer structure, better mobile experience, and more reliable rendering.
This checklist covers the technical and design considerations that make emails work for everyone.
Images and media
All images have alt text. Every <img> tag needs an alt attribute. Describe what the image shows, not just that it's an image. "Product photo of blue running shoes" is useful. "Image" is not.
Decorative images have empty alt. Images that don't convey information (spacers, decorative borders) should have alt="" so screen readers skip them. Don't omit the alt attribute entirely—that causes screen readers to read the filename.
Alt text is concise but complete. Aim for under 125 characters. Describe the essential information. For complex images like charts, provide a text summary nearby.
Images aren't the only way to convey information. If an image contains text, that text should also appear as actual text. If a chart shows data, summarize the key findings in text.
Animated GIFs are used sparingly. Flashing or rapidly changing content can trigger seizures. If you use animation, ensure it doesn't flash more than three times per second. Provide a way to pause animation if possible.
Text and typography
Font size is readable. Minimum 14px for body text, ideally 16px. Smaller text is difficult for many users, not just those with visual impairments.
Line height is adequate. At least 1.5x the font size. Cramped text is hard to read for everyone and especially difficult for users with dyslexia or cognitive disabilities.
Color contrast meets WCAG standards. Text should have at least 4.5:1 contrast ratio against its background (3:1 for large text). Use a contrast checker tool to verify.
Color isn't the only indicator. Don't rely solely on color to convey meaning. "Fields in red are required" fails for colorblind users. Use icons, text labels, or patterns in addition to color.
Text can be resized. Use relative units (em, rem, %) rather than fixed pixels where possible. Users who need larger text should be able to get it.
Structure and semantics
Headings create logical hierarchy. Use heading tags (h1, h2, h3) to structure content. Don't skip levels. Screen reader users navigate by headings—proper hierarchy makes this work.
Tables are used for data, not layout. Layout tables confuse screen readers. Use tables only for actual tabular data. For layout, use other techniques (though email HTML constraints make this challenging).
Data tables have headers. Use <th> for header cells with scope="col" or scope="row". This tells screen readers how to associate data cells with their headers.
Reading order is logical. Screen readers follow the DOM order, not visual order. Ensure the HTML order makes sense when read linearly, even if CSS rearranges things visually.
Language is specified. Include lang="en" (or appropriate language code) on the HTML element. This helps screen readers use correct pronunciation.
Links and buttons
Link text is descriptive. "Click here" and "Read more" are meaningless out of context. Screen reader users often navigate by links—"Read our privacy policy" tells them where the link goes.
Links are visually distinct. Underlines are the most reliable indicator. Color alone isn't sufficient for colorblind users.
Touch targets are large enough. Minimum 44x44 pixels for tappable elements. Small links are difficult for users with motor impairments and frustrating for everyone on mobile.
Links have focus states. Keyboard users need to see which element is focused. Ensure focus styles are visible and distinct.
Forms (if applicable)
Form fields have labels. Every input needs an associated label. Use <label for="fieldid"> or wrap the input in the label element.
Error messages are clear. Explain what went wrong and how to fix it. Don't just highlight the field in red—provide text explanation.
Required fields are indicated. Mark required fields clearly, using text ("required") not just asterisks or color.
Testing accessibility
Test with a screen reader. NVDA (Windows, free), VoiceOver (Mac/iOS, built-in), and TalkBack (Android, built-in) are the major options. Listen to how your email sounds, not just how it looks.
Test keyboard navigation. Can you reach all interactive elements using Tab? Is the focus order logical? Can you activate links and buttons with Enter?
Test with images disabled. Many email clients block images by default. Is your email comprehensible without them?
Test at different zoom levels. Zoom to 200% in your browser. Does the layout still work? Is text still readable?
Use automated tools. WAVE, axe, and similar tools catch common issues. They don't catch everything—manual testing is still necessary—but they're a good starting point.
Email-specific considerations
Preheader text is meaningful. Screen readers may announce preheader text. Make it useful, not just "View in browser" or whitespace.
Plain text version is complete. Some users prefer or require plain text. Ensure your plain text version contains all the information from the HTML version.
Unsubscribe is easy to find. Don't bury it in tiny text. Users who want to unsubscribe should be able to find the option easily.
Common mistakes
Using images of text. Text in images can't be resized, doesn't reflow, and isn't readable by screen readers. Use actual text whenever possible.
Justified text. Full justification creates uneven spacing that's difficult for users with dyslexia. Use left-aligned text.
Low contrast "design choices." Light gray text on white backgrounds might look elegant but fails accessibility requirements. Prioritize readability over aesthetics.
Missing skip links. For long emails, a "skip to main content" link helps keyboard users bypass repetitive navigation.
Frequently asked questions
Do accessibility requirements apply to all emails?
Legal requirements vary by jurisdiction and context. But accessibility benefits everyone—clearer structure, better mobile experience, more reliable rendering. There's no downside to making emails accessible.
How do I test emails with a screen reader?
Send the email to yourself, open it in an email client, and use a screen reader (VoiceOver on Mac, NVDA on Windows). Listen to the entire email. Note where information is missing, confusing, or in the wrong order.
What's the minimum contrast ratio for text?
WCAG AA requires 4.5:1 for normal text and 3:1 for large text (18px+ or 14px+ bold). WCAG AAA requires 7:1 and 4.5:1 respectively. Use tools like WebAIM's contrast checker to verify.
Can I use CSS for accessibility features in email?
Email CSS support is limited and inconsistent. Rely on HTML attributes (alt, lang, scope) rather than CSS-only solutions. Test across clients to ensure accessibility features work.