Email Accessibility in 2026: Why 99.88% of HTML Emails Fail, and What the EAA Means for Your Inbox

Your website might pass an audit. Your checkout might work with a screen reader. And then the order confirmation lands in the customer's inbox as a wall of unlabelled layout tables in the wrong language.

Email is the part of the customer journey that accessibility programmes most often forget. The 2026 Email Accessibility Report from the Email Markup Consortium (EMC) shows how big the gap is: of 376,348 HTML emails analysed, 99.88% contained accessibility issues rated Serious or Critical. Only eight emails, from three senders, passed every automated check. (EMC Accessibility Report 2026)

The good news in the same report: most of the failures are small, mechanical and fixable once at the template level. This guide covers the numbers, what makes email different, the fixes that matter most, and where email fits under the European Accessibility Act.

The 2026 numbers

The EMC collected emails between May 2025 and May 2026 across industries and languages, and tested them with Parcel's email accessibility checker, using Deque axe severity levels.

Highest severity found	Share of emails
Critical	57.97%
Serious	41.91%
Moderate	0.02%
Mild	0.08%
No issues	0.002% (8 emails)

A few findings stand out:

• Nothing has improved. The failure rate was 99.89% the year before. (emailexpert)
• The top failures are basic. Missing dir attribute on the body (97.41% of emails), missing body-level lang (95.66%), layout tables without role="presentation" or role="none" (83.78%), and images with no alt attribute at all (47.88%, rated critical).
• Platforms are part of the problem. The EMC audited 10,566 emails sent through Substack, Shopify and Beehiiv. None passed. Many builders do not even expose settings such as language to the sender.
• Passing automated checks is not the finish line. When the EMC manually reviewed the eight passing emails, it still found issues - alt text that did not match the text inside images, generic alt text, and 10px footer text.
• Email clients lag. The EMC now benchmarks 37 accessibility-related HTML/CSS features. No client supports all of them. Apple Mail on macOS leads with 34, followed by Samsung Email (31) and Proton Mail (29).

Why email is harder than the web

Web accessibility knowledge transfers to email, but not perfectly.

• You do not control the renderer. Gmail, Outlook, Apple Mail and dozens of others each strip or rewrite HTML and CSS differently. Features you rely on in a browser may simply disappear.
• Table layouts are still normal. For robust rendering, especially in Outlook, many teams still build with nested tables. Screen readers announce those tables as data tables unless you tell them otherwise.
• Email is often built by marketers in drag-and-drop tools, not by front-end developers, and the tool's output is what gets sent.
• Dark mode rewrites your colours. Clients invert or adjust colours in ways that can wreck contrast or make transparent logos vanish.

The fix-first list

Ordered roughly by impact and ease. Most of these are one-time template changes.

1. Set language and direction

Screen readers use lang to pick the right voice and pronunciation. Because some clients strip the <html> element, set it on a wrapper as well.

<html lang="de" dir="ltr">
  <body>
    <div lang="de" dir="ltr" style="...">
      <!-- email content -->
    </div>
  </body>
</html>

This alone clears the two most common failures in the EMC data.

2. Mark layout tables as presentational

<table role="presentation" border="0" cellpadding="0" cellspacing="0" width="100%">

Without this, a screen reader user may hear "table, 3 columns, 12 rows" before every block of content. Keep real data tables (an order summary, for example) as proper tables with header cells.

3. Get alt text right

• Every <img> needs an alt attribute. Decorative images and spacers get alt="".
• Informative images get concise, meaningful alt text. If an image contains text - a promo banner saying "30% off until Sunday" - the alt text must say the same thing.
• Linked images need alt text that describes the destination or action.
• Avoid image-only emails. Many clients block images by default, so an image-only email is blank for everyone, not just screen reader users.

For a deeper decision process, see our alt text decision tree.

4. Use real text and real structure

• Put important content in live text, not images.
• Use real headings (<h1>, <h2>) with inline styles rather than styled <td> or <span> elements, so screen reader users can navigate by heading.
• Keep the source order logical. What a screen reader reads should match the visual reading order on mobile.

5. Make links and buttons understandable

• Link text should make sense out of context. "Track your parcel" beats "Click here".
• Build buttons as styled links with real text, not as images.
• Keep tap targets comfortably large for touch.

6. Contrast, size and dark mode

• Aim for at least 4.5:1 contrast for body text (see our colour contrast guide).
• Use body text of 14-16px or larger. Avoid tiny grey legal footers.
• Test in dark mode. Give logos a transparent-safe outline or background, and check that text colours do not collapse into the background after inversion.

7. Include a plain-text part

A well-formatted plain-text alternative helps some assistive technology users, people on constrained clients, and deliverability.

Where email sits under the European Accessibility Act

The EAA applies to specified consumer services - including e-commerce, consumer banking, passenger transport services, e-books and electronic communications - and requires those services, and the information provided about them, to be accessible. The technical benchmark used in practice is EN 301 549, which carries WCAG 2.1 AA requirements to web content and to non-web documents. HTML email most naturally sits in that second group.

A risk-based reading, which is not legal advice:

• Transactional emails that are part of delivering an in-scope service - order and payment confirmations, delivery updates, booking and ticket details, account security and password reset emails, banking notifications - are hard to separate from the service itself. If a blind customer cannot read their booking confirmation or reset their password, the service is not accessible. Treat these as in scope.
• Marketing newsletters are a greyer area. They are less clearly part of "providing the service", but they often carry offers and information that lead into it, and national enforcement practice is still developing. Since the fixes are template-level, the cost of including them is low.
• Your ESP's limitations are not your defence. As with third-party widgets and cookie banners, the obligation sits with the service provider, not the tool vendor. If your platform cannot set lang or produce presentational tables, that is a procurement issue to raise.

How to test email accessibility

1. Automated checks on every template and campaign. Parcel's checker (used for the EMC report) is available on a free plan; many ESPs now include basic checks.
2. Screen reader spot checks on the clients that matter most to your audience - for example VoiceOver with Apple Mail on iOS, and NVDA with Outlook or Gmail in a browser on Windows.
3. Images off. Read the email with images blocked. Does it still make sense?
4. Zoom and mobile. Check at 200% zoom and on a narrow phone screen.
5. Dark mode in at least Apple Mail, Gmail and Outlook.
6. Manual review of alt text against image content - the thing no tool gets right.

Fix it once: templates as infrastructure

The EMC's own recommendation matches what works on the web: the teams getting this right build accessibility into a shared design system or component library, so each fix is made once and inherited by every send. If you already run an accessible design system for your product, extend it to email components - header, button, product card, order summary table, footer - and make your ESP templates consume them.

Checklist

• lang and dir on <html> and on a wrapper element
• role="presentation" on every layout table
• Every image has alt; decorative images use alt=""
• Text in images is repeated in alt text or, better, set as live text
• Real headings in logical order
• Descriptive link and button text; buttons are live text
• Body text 14-16px+, contrast 4.5:1+, checked in dark mode
• Plain-text part included
• Transactional templates tested with a screen reader
• ESP can set language and output accessible markup - or it is on the vendor's roadmap

The bottom line

Almost every commercial email sent today fails basic accessibility checks, and the reasons are mostly boring: a missing attribute, an unmarked table, an image with no alt text. For businesses under the EAA, the transactional emails that confirm, deliver and secure an in-scope service are part of that service. Fix the templates once, test them properly, and your inbox stops undoing the work your web team has done.