Email accessibility — designing email that works for recipients with visual, motor, cognitive, or hearing impairments — serves a larger audience than most email marketers assume. Approximately 15% of the global population lives with some form of disability, and a significant fraction of those disabilities affect how people interact with digital content including email. Beyond the audience size argument, the European Accessibility Act (EAA) came into force in June 2025, requiring digital products and services offered in the EU to meet accessibility standards — and email communications from covered entities are part of that scope. This guide covers the practical accessibility improvements that make email more effective for all recipients and increasingly required by law.
Why Email Accessibility Matters: Business and Legal Case
The business case for email accessibility rests on three arguments: audience reach, deliverability, and legal compliance. The audience reach argument: an email that is inaccessible to screen reader users, recipients with low vision, or recipients with colour blindness is effectively not reaching those subscribers — even when it is technically delivered. Making email accessible converts nominally reached subscribers into actually reached ones. The deliverability argument: accessible email practices (semantic HTML, proper text alternatives for images, reasonable text-to-image ratio) overlap significantly with spam filter content scoring preferences — accessible email tends to score better on content quality metrics than image-heavy, non-semantic email. The legal argument: the European Accessibility Act 2025, the Americans with Disabilities Act (as applied to digital communications), and equivalent regulations in other jurisdictions create compliance obligations for organisations that send commercial email.
The EAA specifically: in force since June 2025, the EAA requires businesses operating in the EU to ensure their digital services — including email communications as part of a broader digital customer journey — meet accessibility standards. The EAA is based on WCAG 2.1 Level AA as the technical accessibility standard. For email marketers reaching EU audiences (which is most global commercial programmes), EAA compliance creates a practical obligation to implement WCAG 2.1 AA accessibility requirements in email design.
Screen Reader Optimization for Email
Screen readers (NVDA, VoiceOver on Apple devices, TalkBack on Android, JAWS) read email content aloud to recipients who are blind or have severe visual impairments. The screen reader experience of a poorly structured email is substantially worse than the visual experience — design elements that convey meaning visually (spacing, colour, positioning) are invisible to the screen reader unless the HTML structure communicates the same meaning semantically.
The key screen reader optimisation practices for email:
Reading order: Screen readers read HTML in document order (top to bottom, left to right in the source code). In multi-column email layouts, the HTML source order must match the intended reading order. A two-column layout where the right column's HTML appears before the left column's HTML will be read right-column-first by screen readers even though the visual layout is left-column-first. Use single-column layouts when possible; for multi-column layouts, verify the HTML source order matches the intended reading order.
Table markup for layout vs data: Email HTML commonly uses tables for layout (positioning columns and sections). Screen readers announce table context — "Table, 3 rows, 2 columns" — before reading the content. For layout tables that are not presenting data, add role="presentation" to suppress the table announcement and prevent screen readers from announcing the layout structure as if it were data. For actual data tables (price tables, comparison tables), use proper <th> headers and scope attributes so screen readers can navigate the table structure meaningfully.
<!-- Layout table: suppress table announcement -->
<table role="presentation" border="0" cellpadding="0" cellspacing="0">
<tr>
<td>Email content here</td>
</tr>
</table>
<!-- Data table: use proper accessibility markup -->
<table>
<thead>
<tr>
<th scope="col">Plan</th>
<th scope="col">Price</th>
</tr>
</thead>
<tbody>
<tr>
<td>Basic</td>
<td>$29/month</td>
</tr>
</tbody>
</table>
Alt Text: Purpose, Length, and Decorative Images
Alt text (the alt attribute on <img> elements) provides text descriptions of images for recipients who cannot see them — whether due to visual impairment (screen reader users) or image loading being disabled (which is common in corporate email environments where images are blocked by default). Alt text is the single most impactful accessibility improvement for most email programmes: it is simple to implement, widely missing, and immediately benefits multiple recipient groups.
Alt text guidelines for email:
Functional images: Images that convey meaningful content (product photos, charts, infographics, event photos) should have alt text that describes the meaningful content. The alt text should be concise (under 150 characters) and describe what the image communicates rather than what it looks like. For a product photo: alt="Red running shoes, size 10, $89" (describing the content value) rather than alt="Photo of red shoes" (describing only the visual).
CTA button images: Images used as call-to-action buttons must have alt text that matches the button's text. alt="Shop now" or alt="Download the guide" — not alt="button" or empty.
Logo images: The company logo should have alt="[Company Name] logo" — the alt text confirms the sender's identity for screen reader users who cannot see the logo.
Decorative images: Images that are purely decorative (background textures, spacing elements, decorative dividers) should have empty alt text (alt="") — NOT missing alt text and NOT a description. Empty alt text explicitly signals to screen readers that the image should be skipped. Missing alt text causes screen readers to read the image filename ("image001-hero-banner-v3-FINAL.jpg") which is meaningless and disruptive to the reading experience.
Text embedded in images: Images that contain text (promotional banners with text, infographics with statistics) should have alt text that includes all meaningful text from the image. Better practice: use HTML text overlaid on the image rather than baking text into the image — this makes the text accessible, searchable, and responsive without depending on alt text accuracy.
Color Contrast and Visual Accessibility
Approximately 8% of men and 0.5% of women have colour vision deficiency (commonly called "colour blindness") — affecting an estimated 300+ million people globally. Red-green colour blindness (the most common form) makes red and green appear similar, which affects emails that use these colours to convey meaning (red for "danger" or "error," green for "success" or "approved"). Email design that relies solely on colour to convey meaning is inaccessible to colour-blind recipients.
The WCAG 2.1 contrast requirements for email: (1) Normal text (below 18pt / 24px) must have at least 4.5:1 contrast ratio against its background. (2) Large text (18pt / 24px or above, or bold 14pt / 18.67px or above) must have at least 3:1 contrast ratio. (3) User interface components and graphical objects (icons, charts, form elements) must have at least 3:1 contrast ratio against adjacent colours. The WebAIM Contrast Checker (webaim.org/resources/contrastchecker/) calculates contrast ratios for any foreground/background colour pair — use it to verify all text/background combinations in email templates before deployment.
Common colour combinations that fail WCAG contrast requirements: light grey text (#999999) on white (#ffffff) — contrast ratio 2.85:1, fails both AA and AAA for normal text. Orange text (#FF6600) on white (#ffffff) — 3.0:1, fails AA for normal text. Light blue text (#6699CC) on white — 3.19:1, fails AA for normal text. These colour combinations appear in many commercial email templates and render unreadably for recipients with low contrast vision even without any clinical visual impairment.
Semantic HTML for Accessible Email
Semantic HTML uses elements that communicate the purpose and structure of content beyond its visual appearance. Screen readers use semantic HTML to provide navigation shortcuts (jumping between headings, reading link text, navigating by landmarks) that make long email content efficiently navigable for screen reader users.
Heading hierarchy: Use heading elements (<h1>, <h2>, <h3>) for email headlines and section headers rather than bold paragraph text styled to look like headings. Screen readers use heading elements to provide a document outline — recipients can jump between sections by heading level rather than reading every word. The heading hierarchy should follow logical order: one <h1> for the email's main topic, <h2> for major sections, <h3> for subsections.
Paragraph elements: Use <p> elements for text content rather than <div> or bare text nodes. Screen readers use paragraph elements to group related content and announce paragraph boundaries.
List markup: Use <ul>/<ol> and <li> for content that is genuinely a list. Screen readers announce list context ("List, 4 items") which helps recipients understand structure. Using asterisks or dashes for visual list formatting is not semantically equivalent — screen readers read the asterisk or dash as text, not as a list indicator.
Link Text and CTA Accessibility
Screen readers often present a list of all links in a document as a navigation shortcut — reading each link's text in sequence. When links use generic text ("Click here," "Read more," "Learn more"), this link list is meaningless: "click here, click here, read more, learn more, click here." Links should use descriptive text that communicates the destination or action without requiring surrounding context.
Accessible link text for email CTAs: "Shop the summer collection" instead of "Shop now"; "Download the 2026 deliverability guide" instead of "Download"; "View your account statement for October 2026" instead of "View statement." The link text should be meaningful when read in isolation.
For button-style CTAs where the visual design uses an image: use a proper HTML button element or an anchor tag (<a>) with descriptive text rather than an image-only button. If an image button is unavoidable, the alt text must contain the full button text. For buttons with icons alongside text, ensure the icon has empty alt text so screen readers do not read the icon description as part of the button text.
European Accessibility Act 2025 and Email
The European Accessibility Act (EAA), Directive 2019/882, became enforceable in EU member states from June 28, 2025. The EAA requires that products and services offered in the EU — including e-commerce services, banking services, and communications services — be accessible to people with disabilities. The technical standard referenced in the EAA for digital accessibility is EN 301 549, which incorporates WCAG 2.1 Level AA.
How the EAA applies to email: the EAA primarily targets the digital service itself (websites, apps, online portals) rather than email as a standalone communication channel. However, email communications that are part of a covered digital service — account notifications, order confirmations, marketing communications from covered e-commerce or banking services — must be accessible as part of the overall service accessibility requirement. The strictest interpretation of EAA requires that all digital customer communications, including email, meet WCAG 2.1 AA standards.
The practical EAA compliance posture for email: implement the accessibility practices documented in this guide (alt text, colour contrast, semantic HTML, descriptive link text). This produces EAA-aligned email design without requiring a separate compliance programme — good email accessibility practices and EAA requirements point in the same direction. For organisations subject to EAA enforcement that have not yet audited their email design for accessibility, conducting an accessibility audit against the WCAG 2.1 AA criteria for current email templates is the first compliance step.
Testing Email Accessibility
Email accessibility testing should be incorporated into the campaign production process as a standard pre-send check, not an occasional audit. The testing methods:
Automated testing tools: Email accessibility tools including the Email Accessibility Checker (provided by Litmus and Email on Acid as part of their testing suites) check for missing alt text, insufficient colour contrast, and missing semantic markup. These tools provide the fastest initial accessibility assessment and catch the most common issues before human testing.
Screen reader testing: Test the email with NVDA (free, Windows) or VoiceOver (built into macOS and iOS) to experience the email as a screen reader user does. Listen for: does the heading structure provide meaningful navigation? Is all important content communicated without relying on visual context? Is all link text meaningful when read in isolation? This testing is more time-consuming than automated checks but reveals issues that automated tools do not detect.
Colour contrast checking: Use the WebAIM Contrast Checker or similar tools to verify all text/background colour combinations in the email template. Document the contrast ratios for each combination — this creates a record of the accessibility review that can be referenced in compliance contexts.
Image-disabled testing: View the email with images disabled (in Gmail, Settings → See all settings → General → Always show images → "Ask before displaying external images"). With images off, verify that all meaningful content is still communicated through alt text and HTML text, and that the email still makes sense and is actionable.
Email accessibility is not a special accommodation for a small minority — it is the design practice that makes email work correctly for all recipients in all conditions, including recipients with visual impairments, recipients in corporate environments with image loading disabled, and recipients using any of the growing range of AI-assisted email tools that process email content programmatically. Accessible email serves everyone better, not only the recipients who depend on it most.