Last updated on

Accessible Email Marketing in 2026: A Developer's Guide to WCAG-Compliant Campaigns

If you send marketing emails, a large chunk of your list is probably struggling to read them — and you likely have no idea which chunk, because none of the usual metrics surface it. Opens and clicks don’t tell you when a subscriber gave up halfway because the alt text was missing, or because the CTA rendered as a 12px grey line on a white background.

This guide is for developers, email engineers, and marketing ops people who build campaigns in something like Mailchimp, Klaviyo, HubSpot, Brevo, or Kit and want to ship emails that pass WCAG 2.2 AA without second-guessing every template.

We’ll cover the numbers, the five broad groups of subscribers you should be designing for, a breakdown of how the common platforms handle accessibility (and where they quietly hand the work back to you), working HTML patterns, and a checklist at the end you can paste into a campaign review doc.

The numbers that should inform your next template

A quick warning: email accessibility stats get recycled aggressively, and a lot of them trace back to one unsourced blog post. These are the ones we can actually cite.

  • 1.3 billion people — roughly 16% of the global population, or 1 in 6 — live with a significant disability. Source: World Health Organization fact sheet on disability.
  • More than 1 in 4 US adults (around 70 million people) report having a disability. Source: CDC, Disability Impacts All of Us.
  • 99.89% of HTML emails tested in 2025 contained accessibility issues rated “Serious” or “Critical”. That’s from the Email Markup Consortium’s 2025 accessibility report, which scanned 443,000+ production emails across industries. Source: Email Markup Consortium Accessibility Report 2025.
  • Around 55% of emails are opened on mobile devices, which matters because mobile is also where screen magnification, dynamic type, and VoiceOver / TalkBack usage spike. Source: Litmus email client market share tracking.
  • 16.7% of screen reader survey respondents reported multiple disabilities; 5.3% reported being both deaf/hard-of-hearing and blind. This matters because “just add alt text” isn’t enough for the subscribers who also depend on braille displays and captioned video. Source: WebAIM Screen Reader User Survey #10.

None of these numbers exist in isolation. If a typical marketing list has 50,000 subscribers, a conservative read of the CDC and WHO data means somewhere between 8,000 and 12,000 of them are affected by at least one condition that interacts with how they read email. That’s not a fringe audience.

The European Accessibility Act (EAA) came into effect on 28 June 2025 and explicitly covers digital communications from companies selling into the EU. The Americans with Disabilities Act (ADA) has been interpreted by US courts to cover digital communications tied to places of public accommodation for several years now. If you’re running an online store with EU or US customers, your email program is in scope.

That doesn’t mean regulators are about to knock on your door because one button had a 3.8:1 contrast ratio. It does mean that a subscriber who can’t read your unsubscribe footer has a clearer path to a complaint than they did three years ago, and that path leads to a data protection authority in their country.

Five types of subscribers — and what each one needs from your email

Most accessibility guides talk about “people with disabilities” as a single bloc. In practice, a template that works well for a VoiceOver user on an iPhone can still break badly for someone using a switch control, and vice versa. It helps to think about concrete groups.

Subscribers with low vision

This is the largest group and the one most marketers underestimate. We’re talking about subscribers who can see the email but are using zoom, dynamic type, high-contrast mode, or just need larger fonts than your brand system allows for. Age-related macular degeneration and diabetic retinopathy are common enough that a sizable share of any list over 40 is in here.

What to do:

  • Don’t pin text inside images — it blurs at 2x zoom.
  • Aim for 16px minimum for body text, 18px is better.
  • Keep contrast ratios at 4.5:1 for body, 3:1 for large text, and test your real brand colours in WebAIM’s Contrast Checker.
  • Respect the user’s font size. Avoid declaring font-size in px on everything; let client defaults scale where you can.

Subscribers who are blind

Screen reader users navigate emails almost identically to web pages: by heading, by link, by landmark. If your “Heading 1” is actually a <div> with 28px font, it doesn’t exist as far as their assistive tech is concerned. They’ll either listen through every word of the email or skip it entirely.

What to do:

  • Use real <h1>, <h2>, <h3> tags for structure. One <h1> per email.
  • Give every meaningful image alt text that conveys the same information as the image. Decorative spacers get alt="", not a missing attribute.
  • Layout tables need role="presentation" so they’re not announced as data tables.
  • Set lang="en" (or the correct code) on the <html> element.

Subscribers with motor impairments

Keyboard-only users, switch device users, tremor, limited fine motor control. For them, tap targets and link order are the whole game. A carousel with 6 tiny product thumbnails packed into one row is a nightmare; a vertical stack of large, clearly-spaced CTAs is easy.

What to do:

  • Minimum 44x44 CSS pixels for any interactive element. This is the WCAG 2.2 AA target size.
  • Leave vertical space between adjacent buttons so a near-miss doesn’t trigger the wrong one.
  • Use real <a> links with text, not image-only buttons.
  • Don’t build anything that requires hover to reveal content. Email clients don’t consistently render hover, and hover isn’t available via keyboard.

Subscribers with cognitive differences

This bucket covers a wide range: dyslexia, ADHD, autism, brain fog from long COVID, chemo-related fog, the normal cognitive load of being a tired human at 9 PM. Dense paragraphs, jargon, and clever word play all act as friction.

What to do:

  • Front-load the point. If the subscriber reads only the first screen, they should still get the offer.
  • Shorter sentences beat elaborate ones. Aim for an 8th-grade reading level; free tools like Hemingway Editor will flag the worst offenders.
  • Use headings to break the email into clearly-labelled sections. Scanning is the default, not the exception.
  • Avoid all-caps for emphasis. Screen readers sometimes spell out all-caps words letter by letter, and it reads as shouting to everyone else.

Subscribers who are deaf or hard of hearing

A smaller group in terms of email-specific impact, but they matter a lot the moment you put video in a campaign. Autoplaying video without captions is functionally invisible to a deaf subscriber, and video-in-email is becoming more common thanks to GIF fallbacks and HTML5 in Apple Mail. Every video needs captions — open captions (burned-in) are safest because caption tracks rarely travel across email clients. Put a transcript link near any audio or video content, and don’t rely on sound for meaning in the first place. If you’re linking to a podcast, describe what’s in it in the body copy instead of just “have a listen.”

Writing alt text that earns its place

Alt text is where most campaigns fall down first. A few rules that actually hold up in production:

Product photos should describe the product and the key visual details that matter to the purchase decision. “Red leather crossbody bag with brass hardware and adjustable strap” beats “handbag” by a mile.

Promotional banners with text baked into the image need to repeat that text in the alt attribute. If the banner image shows “Spring Sale: 30% off everything”, the alt text says exactly that. Don’t describe the design of the banner — describe what it says.

Decorative images (spacer pixels, bullet dividers, purely ornamental flourishes) get alt="". An empty alt attribute isn’t a mistake, it’s a specific instruction to the screen reader: ignore this, it’s not content.

Charts and infographics need a written summary of the key takeaway. “Bar chart showing customer satisfaction increased from 72% to 91% after our accessibility overhaul” conveys the finding without requiring the picture.

Logos get the company name as alt text. alt="Acme Corp", not alt="Acme Corp logo". Screen readers already announce it as an image, so “logo” is noise.

A quick sanity check: if you hide every image in the preview, does the plain-text fallback still make sense? If not, your alt text is doing too little — or the email is doing too much with images.

The HTML patterns that actually work

Most email platforms generate reasonable HTML if you stick to their native blocks. When you drop into custom HTML — and eventually you will — these are the patterns that behave across Gmail, Outlook, Apple Mail, and the long tail.

A layout table should always carry role="presentation":

<table role="presentation" cellpadding="0" cellspacing="0" border="0" width="100%">
  <tr>
    <td align="center">
      <!-- content -->
    </td>
  </tr>
</table>

A button in email is still, realistically, a styled anchor wrapped in a table cell. The critical bit is that the text lives in the anchor, not in an image:

<a href="https://example.com/sale"
   style="display:inline-block;padding:14px 28px;
          background:#1a4d8f;color:#ffffff;
          text-decoration:none;border-radius:4px;
          font-size:16px;font-weight:600;">
  Shop the spring sale
</a>

Set the lang attribute on the root element so screen readers don’t try to pronounce French words with English phonetics:

<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Your order has shipped</title>
  </head>
  ...
</html>

Headings are real tags, not styled divs. If you need a specific font size, style the heading tag:

<h2 style="font-size:24px;line-height:1.3;margin:0 0 16px;">
  This week's picks
</h2>

None of this is exotic. It’s the same HTML you’d write for a well-built web page in 2012, and that’s sort of the point: email accessibility is mostly about rolling back the clever layout tricks that break assistive tech.

Platform walkthroughs

Every platform in the list below ships some accessibility tooling. None of them cover everything. The split below is intentional: what the platform does for you, versus what you still have to fill in.

Mailchimp

What it does well: Mailchimp’s classic builder produces semantic headings when you use the Heading content block, and the Inbox Preview tool flags common contrast issues and missing alt text. The platform’s newer “accessibility checker” runs over your draft before send and highlights specific failures rather than giving a vague score.

What you need to add manually: alt text is not auto-generated, and the checker doesn’t catch decorative-image false positives, so empty-alt decisions are still on you. Multi-column layouts in the drag-and-drop builder sometimes reorder unpredictably on mobile — test the linearised reading order by viewing source on a rendered test send.

Klaviyo

What it does well: Klaviyo’s drag-and-drop editor uses semantic <h1>/<h2> tags when you pick the Heading block, and alt text is a first-class field on every image block. The new email editor (rolled out through 2025) includes a contrast warning on text blocks with under-4.5:1 ratios.

What you need to add manually: Klaviyo’s pre-built templates vary. Some older ones use decorative images in place of text for section headers, and those carry no accessible text fallback unless you edit them. Klaviyo also doesn’t yet set lang on the <html> element automatically if you’re outside a English-only account — worth checking your template source.

HubSpot

What it does well: HubSpot’s drag-and-drop email editor generates reasonably clean semantic HTML, and the Marketing Hub editor surfaces accessibility warnings for missing alt text, empty links, and insufficient contrast inline. Smart content blocks (dynamic content) inherit the parent template’s heading structure rather than breaking it.

What you need to add manually: Custom modules written in HubL often skip accessibility review entirely because the checker runs on the compiled email, not the module source. If your team ships custom modules, bake alt-text fields and ARIA attributes into the module schema so content editors can’t accidentally omit them.

Brevo (formerly Sendinblue)

What it does well: Brevo’s template builder generates semantic HTML and exposes an alt-text field on every image. It’s also one of the few platforms that auto-adds role="presentation" on layout tables in its default templates, which saves you one category of manual fix.

What you need to add manually: The transactional API lets you send arbitrary HTML, and there’s no accessibility check on that path. If your shipping-confirmation template was hand-coded two years ago, it’s probably not accessible. Run it through a WAVE or axe pass — paste the rendered source into a blank HTML file first.

Kit (formerly ConvertKit)

What it does well: Kit’s broadcast editor produces very clean HTML by default, partly because it aggressively limits layout options. Heading blocks map to real heading tags, images have required alt-text fields (you’ll see a warning before send if one is empty), and the default templates pass WCAG 2.2 AA on contrast out of the box.

What you need to add manually: Kit’s simplicity is a feature, but if you need anything beyond single-column layouts you’ll be in custom HTML territory, and custom HTML gets no built-in accessibility review. Also worth noting: the “visual” email builder and the “text-only” broadcasts produce different HTML, and the text-only ones skip some of the semantic scaffolding that screen readers lean on. Check both formats.

The email accessibility checklist

Run this over every major campaign before you hit send. 20 items, grouped so you can delegate the review across a team if you want.

Structure

  1. Exactly one <h1> in the email, matching the core message or subject.
  2. Headings used in order (no h1 -> h3 jumps).
  3. Real <p> tags for body text, not stacks of <br>.
  4. Layout tables have role="presentation".
  5. lang attribute is set on the <html> element.

Images

  1. Every meaningful image has alt text that conveys the same information.
  2. Decorative images have alt="" (empty, not missing).
  3. No critical text is pinned inside an image with no text fallback.
  4. Logo alt text is the company name, not “[brand] logo”.

Colour and contrast

  1. Body text meets 4.5:1 contrast on its actual background.
  2. Large text (18px+ or 14px+ bold) meets 3:1 contrast.
  3. No information is conveyed by colour alone (sale price, status indicators, etc.).
  4. Dark-mode rendering has been spot-checked in at least Apple Mail and Outlook.

Interaction

  1. Buttons and links are at least 44x44 CSS pixels.
  2. CTA link text is descriptive on its own (“Shop the sale”, not “Click here”).
  3. Adjacent clickable elements have vertical space between them.
  4. Nothing depends on hover to be revealed.

Language and content

  1. Subject line and preheader are readable without the images.
  2. The first screen of the email conveys the core message.
  3. Plain-text version of the email makes sense on its own — check by previewing text mode in the platform.

Copy that into a Notion doc, a Google doc, or your internal wiki and use it as a pre-send gate. If you want a ready-made copy, it’s linked from our 5-minute accessibility audit guide.

Testing without a full assistive-tech lab

You don’t need a NVDA licence and a second laptop to catch 80% of the problems. A small rotation works:

Send yourself a test. Open it on your phone with VoiceOver or TalkBack turned on for two minutes. Swipe through the email as a screen reader user would — you’ll hear every alt text, every link, every heading, and you’ll immediately notice the ones that announce “image” or “link link link” instead of meaningful text.

Then open the same test on desktop and tab through it. Can you reach every CTA? Does the focus indicator show up, or is it invisible against the background?

Finally, view the email in plain-text mode inside your platform (every serious platform has this). If the plain-text version doesn’t make sense on its own, there’s content that only exists in images or in visual styling — and that content is invisible to a chunk of your audience.

That’s three checks, maybe ten minutes of work per campaign. It catches most of what an automated scanner would miss.

Dark mode, forced colors, and the stuff that breaks unexpectedly

One thing that catches a lot of teams off guard: the email you approved on your monitor looks completely different to a subscriber whose OS is in dark mode, or whose mail client forces a colour palette for low-vision reading.

Apple Mail, Outlook (on some versions), and Gmail all apply automatic dark-mode transformations to emails, and they do it differently. Apple Mail usually inverts backgrounds but preserves brand colours on logos. Outlook sometimes leaves the email as-is, sometimes forces a dark background behind your light-mode layout, producing unreadable grey-on-grey text. Gmail’s Android app can partially invert, which is the worst of both worlds because half your design stays the same and half flips.

A few practical rules:

  • Test your most-used template in dark mode in at least Apple Mail iOS, Outlook desktop, and Gmail Android before you commit to it as a house template. You only have to do this once per template, not per campaign.
  • Avoid transparent-background PNG logos that rely on being viewed against white. They vanish on dark backgrounds. Use a version with an explicit background colour, or provide a dark-mode-specific asset via the @media (prefers-color-scheme: dark) query where supported.
  • Don’t use pure black (#000000) or pure white (#ffffff) for body text. Near-black on near-white (#1a1a1a on #f8f8f8, for example) is easier on eyes with photosensitivity and inverts more predictably in dark mode.

Forced-colors mode (Windows High Contrast) is a separate concern but affects a smaller slice of email users, because most desktop email clients don’t fully honour it. If you’ve got a corporate audience on Outlook Windows, test there; otherwise, getting your regular contrast ratios right already covers most of what forced-colors would catch.

One more thing about automation

Automated accessibility checkers (including the built-in ones in Mailchimp, Klaviyo, and HubSpot) are good at finding specific, pattern-matchable failures: missing alt, contrast under threshold, empty links. They’re not good at judgement calls — is the alt text actually meaningful? Is the reading order logical? Is the button text still useful out of context? Those need a human.

Treat automated checks as a floor, not a ceiling. They’ll flag the 30% of issues that are mechanical. The other 70% is design choices.

We’re building a simple accessibility checker aimed at marketers and developers who don’t want a full enterprise suite — no DevTools, no jargon, just “here’s what’s broken and here’s how to fix it”. Join the waitlist for early access.