Email Accessibility in 2026: Fixing What 99.88% of Senders Get Wrong

The Email Markup Consortium tested 376,348 emails collected between May 2025 and May 2026. Eight passed. That is a pass rate of 0.002%, and those eight came from just three brands. 99.88% of the sample carried at least one accessibility defect rated “Serious” or “Critical” by automated testing.

That number would be an academic curiosity if the European Accessibility Act had not come into force on 28 June 2025. It applies to any company selling products or services into the EU, not just companies based there. Suddenly the gap between “our emails look fine” and “our emails work for everyone” carries legal weight in 27 member states.

The encouraging part: most of what fails is boring. Missing attributes, missing alt text, low contrast. These are one-time template fixes, not a redesign.

Prerequisites

Before you start, you need:

• Access to your email HTML. Either a custom HTML editor in your platform, or the ability to edit a master template. If your platform locks the HTML entirely, skip to “What Your Platform Controls”: your options are different.
• A free accessibility checker. Parcel’s accessibility checker is the same tool the EMC used for its report, and it is included on Parcel’s free Community plan.
• One recently sent campaign to test against. Do not start with a blank template. Start with what you actually send.
• Thirty minutes. The first six fixes below take about that long on a single template.

You do not need to be a developer. You need to be able to paste attributes into HTML tags and tell whether text is legible.

Step 1: Add lang and dir Attributes

These two are the most common failures in the entire dataset, and they are the easiest to fix.

The dir attribute was missing from the body content of 97.41% of emails tested. The lang attribute was missing from body content in 95.66%, and missing from the <html> element itself in 62.16%.

Why it matters: email clients inherit the user’s own language and direction settings into your content. A subscriber reading in Arabic or Hebrew opens your English email and gets a layout that reads right-to-left. Screen readers, meanwhile, use lang to pick a pronunciation engine: without it, an English email may be read aloud with German phonetics.

The fix is three attributes:

<html lang="en" dir="ltr">
  <body>
    <div lang="en" dir="ltr">
      <!-- all your content goes inside here -->
    </div>
  </body>
</html>

The inner <div> matters because several clients strip attributes from <html>. If you cannot determine the language programmatically, lang="und" and dir="auto" are weak fallbacks, worse than the correct value, far better than nothing.

Step 2: Mark Layout Tables as Presentational

83.78% of tested emails used tables for layout without telling assistive technology to ignore them. A screen reader encountering an unmarked table announces it as a data table: “table, four columns, twelve rows.” Your subscriber then navigates cell by cell through what is actually a two-column newsletter.

Add one attribute to every layout table:

<table role="presentation" cellpadding="0" cellspacing="0" border="0">

If a table genuinely holds tabular data (an order summary, a pricing grid) leave the role off and add proper <th> headers instead. The distinction is whether the rows and columns carry meaning.

Step 3: Write Alt Text That Earns Its Place

47.88% of emails had images with no alt attribute at all. This is the most common Critical-severity failure in the report.

Three rules:

1. Every <img> needs an alt attribute. Not every image needs description: decorative spacers and background flourishes take alt="", which tells a screen reader to skip them.
2. Linked images are never decorative. If an image is wrapped in an <a>, its alt text is the link text. This is why 71.23% of emails failed the “links must have discernible text” check: the culprit is usually a linked hero image or logo with no alt.
3. Describe the destination, not the picture. For a linked product image, “Shop the Merino crew neck, £89” beats “photo of a grey sweater.”

Step 4: Fix Colour Contrast

58.48% of emails had at least one element with insufficient contrast. The threshold under WCAG 2.1 AA is 4.5:1 for body text and 3:1 for large text, roughly 18pt and above, or 14pt bold.

The offenders are predictable: light grey footer text, white text on a pale brand colour, and disclaimer copy set at 10px in a grey that looks refined on a designer’s calibrated monitor and vanishes on a phone in daylight.

Check your palette once, then encode the results in your template. Two combinations to audit first: your primary CTA button (text against button fill) and your footer block. Those two account for most of the failures we see in real templates.

Step 5: Add a Heading and a Title

74.23% of emails had no <h1>, and 45.21% had no <title> element.

Screen reader users navigate documents by heading. Without an <h1>, there is no entry point into your content: the reader starts at the top and works through the preheader, the logo, the navigation, and the view-in-browser link before reaching anything useful.

<title>Your July product update</title>
...
<h1 style="font-size:28px; margin:0 0 16px;">Three things shipped this month</h1>

Use real heading tags with inline styles rather than styled <div> or <span> elements. Headings should descend in order (<h1>, then <h2>) without skipping levels. Short transactional emails may not need a heading at all, which is why the EMC rates this as a Mild issue rather than Serious.

The <title> only surfaces in the browser version of your email. If you offer a “view in browser” link, it needs one.

Step 6: Make Link Text Descriptive

15.83% of emails used non-descriptive link text like “click here” or “read more.” That figure understates the problem: the EMC’s check only scans English-language phrases.

Screen reader users often navigate by pulling up a list of every link in a document, stripped of surrounding context. A list that reads “click here, click here, learn more, click here” is useless. “Read the pricing guide, book a demo, see the changelog” is not.

What Your Platform Controls

Here is the part most guides skip: on several popular platforms you cannot fix any of the above, because you never touch the HTML.

For its 2026 report the EMC audited 10,566 emails sent through three platforms that own the generated markup. None passed.

Platform	Emails audited	Critical	Serious
Substack	6,909	83.77%	16.23%
Shopify Email	1,468	84.67%	15.33%
beehiiv	2,189	46.41%	53.59%

The failure patterns are systemic rather than user error. On Substack, 99.96% of emails had contrast issues (only 3 of 6,909 passed) which points at platform defaults, not writer choices. On beehiiv, 99.59% had non-descriptive link text, suggesting a default link label applied at scale. On Shopify, 99.59% of layout tables were missing the role attribute and 100% lacked a language setting.

Substack remains the fastest way to start a paid newsletter, and its subscriber-discovery network is something no self-hosted setup replicates. The accessibility weakness is structural: you cannot upload custom HTML, so the contrast and link-text failures are not yours to fix.

beehiiv gives creators more control over layout, monetisation and analytics than Substack does. It also generated the lowest Critical-issue rate of the three platforms audited, 46.41% versus 84%-plus. That is a meaningfully better starting point, but it is still 100% failure against the full checklist, and beehiiv likewise does not accept custom email templates.

If accessibility is a compliance requirement rather than a preference, you need a platform with a custom HTML editor. MailerLite includes one on every plan, including the free tier: its FAQ confirms all three editors (drag-and-drop, custom HTML, and simple) are available at no cost. That lets you set lang, dir, role and <title> yourself. The weaknesses are real: the free plan caps at 250 subscribers and 2,500 emails per month, and the drag-and-drop editor does not expose language or direction settings, so the fixes only apply to templates you hand-build in HTML mode.

Brevo also supports custom HTML with head-level code injection, which covers the same set of fixes. Its design tooling is more basic than MailerLite’s, and the entry paid tier limits contacts. Check current terms at brevo.com/pricing before committing.

Worth noting: Customer.io was one of only three senders in the entire 376,348-email dataset whose emails passed automated testing. That reflects the discipline of Customer.io’s own marketing team as much as the product, and Customer.io is a developer-oriented platform priced well above the tools above, but it demonstrates the standard is reachable.

The Client Problem You Cannot Fix

Even a flawless template runs into email clients that strip the markup.

The EMC tested 43 clients against 37 accessibility-related HTML and CSS features. No client supported all 37. More than half (25 of 43) supported fewer than half.

• Apple Mail (macOS): 34/37, the highest score
• Samsung Email (Android): 31/37
• Proton Mail: 29/37 on desktop and iOS
• Gmail: 15/37 to 17/37 depending on platform
• Outlook (Windows, legacy): 11/37

Gmail does not reliably support prefers-color-scheme or prefers-reduced-motion, and its forced dark mode overrides sender colour choices, which is how carefully checked contrast ratios turn into failures at delivery. Microsoft’s deprecation of the legacy Windows Outlook rendering engine should improve the bottom of that table over time.

The practical consequence: build to the standard anyway. Clients that support role="presentation" and lang will honour them, and the ones that strip them are no worse off than before.

Common Mistakes

Treating accessibility as a post-build checklist. The EMC’s central recommendation is to move checks into the build itself, contrast validated as a colour is picked, alt text prompted as an image is added. Fixing a template once and letting it drift for six months reproduces the problem.

Assuming a template purchase solves it. Paid templates are built for rendering compatibility, not accessibility. Test one before you buy.

Trusting automated tools completely. Automated checks caught the syntax failures above. They cannot tell you whether alt text describes the image, whether link text matches its destination, or whether your reading order makes sense. Manual review with a screen reader (VoiceOver on macOS is free and takes ten minutes to learn the basics) remains necessary.

Exempting transactional email. Order confirmations and password resets are service communications and fall inside the EAA’s scope. They are also the emails people most need to read.

Assuming the EAA does not apply to you. It covers non-EU companies serving EU customers. There are carve-outs (microenterprises, and a “disproportionate burden” defence) but they must be argued, not assumed. Read the directive text if you are close to a threshold.

What Success Looks Like

Run your last campaign through an accessibility checker. You are in reasonable shape when:

1. lang and dir are set on the <html> element and on a direct child of <body>.
2. Every layout table carries role="presentation", and every data table carries real <th> headers.
3. Every image has an alt attribute: descriptive where it carries meaning, empty where it does not, and never empty on a linked image.
4. Body text hits 4.5:1 contrast and no copy sits below 12px.
5. There is one <h1>, headings descend in order, and a <title> exists if you offer a browser version.
6. Link text reads sensibly out of context. Read your links aloud as a list. If you cannot tell where they go, rewrite them.

That is six checks. On a single master template it is an afternoon’s work, and every campaign built from that template inherits the result.

For related reading, see our guides to designing emails for dark mode (which interacts directly with contrast) and email marketing and GDPR compliance. If you are choosing a platform with these constraints in mind, our best newsletter platforms roundup compares HTML control across the field.

The email industry has been at roughly 99.9% failure for four consecutive reports. The individual fixes are trivial; what is missing is anyone treating them as required. Whichever platform you use, the six checks above will move you further than most of the 376,348 emails the EMC tested.

Sources

1. Email Markup Consortium — Accessibility Report 2026 — accessed 2026-07-30
2. European Accessibility Act (Directive (EU) 2019/882) — accessed 2026-07-30
3. W3C — Web Content Accessibility Guidelines (WCAG) — accessed 2026-07-30
4. MailerLite — Pricing — accessed 2026-07-30