The newsletter accessibility checklist (EAA-ready)

Put 28 June 2030 in the calendar. That is when the automations and drip sequences you shipped before June 2025 stop being covered by the transition period in the European Accessibility Act. Every newsletter accessibility checklist on the internet will tell you to write alt text and check your contrast, and both are right, but neither explains why the same failures keep reappearing in send after send from teams who genuinely care.

They reappear because they are not writing mistakes. They are template output.

What the European Accessibility Act actually requires of email

Directive (EU) 2019/882 has applied since 28 June 2025. Services already on the market before that date get a transition period that ends on 28 June 2030, which is the deadline that matters for anyone with a welcome sequence written three years ago and never opened since.

The requirement chain is worth naming, because most articles skip it and leave readers guessing at a standard. The Act points at the harmonised European standard EN 301 549, and EN 301 549 adopts WCAG 2.1 level AA from the W3C for digital content. So when someone asks what level their newsletter has to hit, the answer is WCAG 2.1 AA, arrived at through two documents that never mention the word newsletter.

Scope is narrower than the panic suggests. The Act covers consumer-facing services: ecommerce, banking, e-books, transport, telecoms. If your email is part of delivering one of those to consumers in the EU, you are in. A B2B newsletter selling observability software to platform teams is mostly outside it, and the vendors currently emailing that audience about compliance deadlines know this.

Here is the position we will defend anyway: scope is the least interesting question on this page. The same template renders for both audiences, the fix costs one afternoon, and the failure modes below are already costing you readers who never complain. They just stop opening.

What the source HTML gives away

Newsletrix stores the full source HTML of every tracked send in a raw_html column rather than a rendered screenshot, and it identifies the sending platform from the RFC822 headers before parsing anything. That combination is what makes accessibility auditable after the fact instead of at design time. You can go back through an archive of real, in-the-wild sends and count the machine-checkable signals: the alt attribute on every <img>, role="presentation" on layout tables, lang and dir on the document and body, whether a non-empty <title> exists, whether headings are real <h1> and <h2> tags or styled <span> elements, inline font sizes, and the text inside each anchor.

Group those signals by detected platform and the shape of the problem changes. You stop looking at a list of individual senders who made mistakes and start looking at a handful of template generators, each with its own default behaviour, reproduced across thousands of brands who never touched the markup.

The Email Markup Consortium publishes the largest public version of this analysis, and its 2026 report covers 376,348 emails collected between May 2025 and May 2026. Of those, 99.88% contained defects rated Serious or Critical: 57.97% Critical, 41.91% Serious. Eight emails passed every automated check. Eight, from three brands: Customer.io, NaomiWest.ca and Noble Panacea.

One row in that table moves the wrong way. Missing alt text improved by three and a half points year on year, layout table roles improved by two and a half, and the <title> element got worse, from 41.35% missing to 45.21%. The item that every checklist puts first got better. The invisible one, which no design review ever catches because nothing looks wrong, slid backwards. That is what a decade of alt-text advocacy buys you: one fixed item and no mechanism for the rest.

The platform breakdown in the same report is blunter. Across senders with at least six months of data, Substack failed on all 6,909 emails tested, beehiiv on all 2,189, Shopify on all 1,468. Not most. All of them. No individual marketer on those platforms can fix that from inside the editor.

The 12-point newsletter accessibility checklist

Work through this against the HTML of your last send, not against the preview pane. Half of these are invisible in a render.

1. Every <img> carries an alt attribute. Spacers, dividers and decorative flourishes get alt="" with nothing inside, which is a pass and tells assistive technology to skip them silently. A missing attribute is what makes a screen reader read out the file name.
2. Layout tables carry role="presentation". Without it, NVDA announces the grid before your headline.
3. The <html> element has a lang attribute and the body has lang and dir. These are the two most common defects in the EMC data and the two cheapest to fix.
4. A non-empty <title> element exists. Web-view archives and some clients read it first.
5. Headings are real <h1> and <h2> tags rather than a bold <span> at 24px. Screen reader users navigate by heading; styled spans give them nothing to jump between.
6. Source order survives linearisation. If a two-column module reads "Buy now" before the product name when flattened, the reading order is wrong even though the render looks fine.
7. Body text meets 4.5:1 contrast against its background, large text 3:1 (WCAG 2.1 SC 1.4.3). Grey on white at #999 fails, and it is everywhere.
8. Body copy sits at 16px with 14px as the floor, and no part of the message lives inside an image.
9. Link text describes its destination. Screen reader users can pull up a list of every link with no surrounding sentence, and a page of "click here" is useless in that view.
10. Buttons are HTML and CSS rather than image-only, so they survive images-off and can be read aloud.
11. Dark mode does not destroy the contrast you set. Forced inversion on Outlook and Gmail regularly turns a compliant palette into a failing one, which we cover in the dark mode design playbook.
12. The plain-text part is a real alternative rather than a one-line pointer to the web version.

Why the newsletter accessibility checklist belongs in your ESP template

Sort those twelve by where the fix lives and the workload collapses. Eight of them are template properties: the role attribute, lang, dir, the title element, heading tags, the font-size floor, button markup and the colour tokens that decide contrast. Set them once in the master template and they ship correctly forever, including in the issues written by whoever replaces you.

Four are genuinely per-send: alt text for this week's images, link text for this week's links, source order for any new module, and the plain-text part. That is the real recurring workload, and it is about ten minutes of an editor's time.

This is why we think the checklist is the wrong unit of work. A checklist run every issue implies twelve recurring decisions when there are four. Teams feel the weight of twelve, skip the run, and ship the same eight defects for a year.

The tradeoff is real, so here it is. Bulletproof HTML buttons and semantic heading tags cost you visual fidelity in the Outlook Word rendering engine, where border-radius is ignored, VML fallbacks get verbose, and an <h2> arrives with margins you did not ask for. Designers push back on this, and they are not being difficult. You are trading a few pixels of polish in one client for a document that can be read at all in another. We take that trade every time, but say it out loud rather than pretending the cost is zero.

If your platform will not let you touch the template, that is worth knowing before you buy rather than after. Litmus tests accessibility inside a design workflow, which is a different job from auditing what already went out; our Litmus comparison lays out where each fits.

How to test a newsletter in 15 minutes

Send yourself the real thing. Previews lie, because the client is what mangles the markup.

On Windows, open the send in Outlook with NVDA running and listen to the first thirty seconds. You are checking whether the headline arrives before any table structure, and whether images announce something meaningful. On a Mac or an iPhone, VoiceOver plus Apple Mail gets you the same answer. JAWS behaves close enough to NVDA for this pass that you do not need both.

Then zoom the browser view to 200% and check that nothing gets clipped or overlapped. Read the source order top to bottom in the raw HTML: that is the sequence a screen reader follows, regardless of how the columns look.

Finish with the automated pass. The alt-text auditor catches missing and junk alt attributes, and the Flesch-Kincaid calculator tells you whether the copy is readable once the visual hierarchy is stripped away, which matters more than usual when the reading order is linear. Sentence length does real work here, and the readability sweet spot and newsletter length pieces both apply.

Automated checks catch the machine-readable half and stop there. No tool can tell you that "Product photo" is a worse alternative than "The blue running shoe in three colourways", which is the part of writing alt text that stays human. And if you want to know which platform a competitor's template comes from before you copy its structure, the ESP detector will tell you.

One more thing worth doing while you are in the template: check the footer at the same time. The footer compliance checklist and this one overlap on link text and contrast, and the unsubscribe link is the single control a frustrated subscriber reaches for first.

Frequently asked questions

Does the European Accessibility Act apply to marketing emails?

Indirectly, and only for some senders. Directive (EU) 2019/882 covers services such as consumer ecommerce, banking, e-books, transport and telecoms. If your email is part of delivering one of those services to consumers in the EU, it falls in scope. A pure B2B newsletter selling software to procurement teams usually does not. The Act has applied since 28 June 2025, and services provided before that date have a transition period to 28 June 2030.

What WCAG level do newsletters need to meet?

WCAG 2.1 level AA. The European Accessibility Act points at the harmonised standard EN 301 549, which adopts WCAG 2.1 AA for digital content. In practice that means 4.5:1 contrast for body text, 3:1 for large text, a programmatic reading order, a language attribute, and text alternatives for images.

Should decorative images have empty alt text?

Yes. A spacer GIF, a divider line or a background flourish should carry alt="" with nothing inside it. That is a pass, not a failure. An empty alt tells a screen reader to skip the image silently. A missing alt attribute makes the same screen reader read out the file name, which is how subscribers end up hearing hero-final-v3-retina.png.

What is role="presentation" in an email table?

Almost every HTML email uses tables for layout rather than for tabular data. Without role="presentation" on those tables, a screen reader announces the grid structure before the content, so the subscriber hears something like table with four rows, two columns ahead of your headline. Adding the attribute makes assistive technology ignore the scaffolding and read the content. The Email Markup Consortium found layout tables missing a role attribute in 83.78% of the 376,348 emails it tested for its 2026 report.

What font size is accessible in email?

Set body copy at 16px and treat 14px as the floor. Below that, Gmail on Android and Apple Mail on iOS start applying their own text scaling, which breaks layouts that were pinned to a fixed pixel width. Never carry the message inside an image, because image-only text has no size a reader can change and no alternative a screen reader can announce.

Related reading