Email is the channel that marketing and content teams control most directly themselves: newsletters, product announcements, order confirmations, shipping notices, password mails. Yet this very medium is usually left out of the accessibility debate, even though it reaches millions of inboxes every day. The latest Accessibility Report by the Email Markup Consortium examined 376,348 (Email Markup Consortium, 2026) HTML emails over a year and found serious or critical barriers in 99.88 percent (Email Markup Consortium, 2026) of them. For transactional emails that are part of an electronic ordering process, this is not a cosmetic problem but a question of the BFSG requirements. This article shows how newsletters and automated mails become accessible under WCAG 2.1, from the lang attribute through alt text to dark mode robustness, and where a structured WCAG audit makes the gaps visible.
When Emails Fall Under the BFSG
The German Accessibility Strengthening Act (BFSG) has applied since 28 June 2025 (BFSG) and transposes the European Accessibility Act (Directive EU 2019/882) into German law. It requires certain digital services to be offered accessibly and, for technical implementation, references the harmonized standard EN 301 549, which in turn points to the WCAG success criteria. Why this EN 301 549 standard forms the yardstick behind the BFSG is something we place in context in a separate article. For emails, the decisive question is whether a message belongs to the service itself or is pure advertising.
An order confirmation, an invoice, a shipping notice or a password mail is inseparable from electronic commerce: without it, the purchase cannot be completed or the account cannot be used. Such transactional emails are therefore part of the service's user interface and should meet the same standard as the shop itself. A purely promotional newsletter that merely draws attention to offers, by contrast, is not automatically a service in its own right within the meaning of the law. The specific classification depends on the individual case and does not replace legal advice.
The Yardstick Is Fixed
Transactional Email or Promotional Newsletter
The dividing line between obligation and good practice does not run along the sender address, but along the purpose. Anyone who cleanly distinguishes the two categories can prioritize effort without dropping the aspiration to accessibility. The following overview classifies the common email types.
| Email type | Typical examples | Classification | Recommendation |
|---|---|---|---|
| Transactional email | Order confirmation, invoice, shipping, password reset | Part of the electronic service | Make accessible under WCAG |
| Service email | Appointment reminder, status update, account notice | Closely tied to the service | Treat like transactional email |
| Promotional newsletter | Offers, discounts, content digest | Usually not a service in its own right | Accessible as a standard and reach advantage |
| Hybrid | Newsletter with an invoice link or account function | Classification case by case | When in doubt, apply the stricter standard |
For promotional newsletters, the underlying idea of the General Equal Treatment Act (AGG) also applies: anyone who systematically excludes part of their audience risks not only reach but also a disadvantage that runs counter to the principle of equal treatment. Accessible newsletters therefore make sense even where there is no immediate BFSG obligation, as a standard that shuts no one out and widens your own reach.
Classification Does Not Replace Legal Advice
The State of Accessible Email in Numbers
The data is clear and sobering. Of the 376,348 (Email Markup Consortium, 2026) HTML emails tested in the reporting period, only eight passed all automated tests. Most often, basic building blocks were missing that have long been standard on the web. Six findings stand out and can be traced directly to concrete WCAG criteria.
Language Not Declared
In 62.16 percent (Email Markup Consortium, 2026) of emails, the lang attribute is missing from the html tag, so screen readers choose the wrong pronunciation (WCAG 3.1.1).
Images Without an Alternative
47.88 percent (Email Markup Consortium, 2026) of images carry no alternative text and stay empty for screen readers and when images are blocked (WCAG 1.1.1).
Tables Without a Role
83.78 percent (Email Markup Consortium, 2026) of layout tables are not marked as pure layout, which disrupts the reading order (WCAG 1.3.1).
Meaningless Links
71.23 percent (Email Markup Consortium, 2026) of emails contain links with no discernible text, and a further 15.83 percent (Email Markup Consortium, 2026) only vague labels (WCAG 2.4.4).
Text as an Image
Whole campaigns are sent as a single graphic. If images are blocked or read aloud, the message stays invisible (WCAG 1.4.5).
Contrast Too Weak
Delicate grey tones on white and pale buttons often fall below the required contrast of 4.5:1 for normal text (WCAG 1.4.3).
Automated Tests Are Only the Start
Declaring Language: The lang Attribute
A screen reader decides which pronunciation engine to use based on the declared language. Without the declaration, an English voice may read out a German newsletter, and the result is barely intelligible. Success criterion 3.1.1 therefore requires the document's primary language to be programmatically determinable, and criterion 3.1.2 adds individual language changes within the text. In practice this means the email's html element gets a lang attribute, and foreign-language passages are marked separately.
<!-- Declare the primary language of the email -->
<html lang="en" dir="ltr">
<body>
<h1>Your order is on its way</h1>
<p>Thank you for your purchase.</p>
<!-- Mark a language change separately -->
<p>Our motto: <span lang="de">immer neugierig</span>.</p>
</body>
</html>A Small Addition, a Big Effect
Real Text Instead of an Image Email
A common mistake is the image email: the entire message, that is, heading, body text and button, is designed as a single graphic and sent. This looks perfect in the design preview but fails against the reality of inboxes. Many email programs block external images by default; then, instead of the message, an empty area remains. A screen reader cannot read an image aloud anyway, and anyone who enlarges the text gets only a blurry pixel mush. Success criterion 1.4.5 explicitly advises against text as an image wherever real text is possible.
- Real text is readable aloud: Only machine-readable text reaches screen readers and speech output (WCAG 1.1.1, 1.4.5).
- Real text scales: On zoom it stays sharp, whereas text in images pixelates and becomes hard to read.
- Real text survives image blocking: If image loading is disabled, the core message stays visible anyway.
- Alt text for content-bearing images: Product photos and graphics that carry meaning need an apt description; purely decorative images get an empty alt attribute.
- Meaningful preheader: The leading preview text does not replace alt text but helps everyone judge the relevance of a mail quickly.
Images Complement the Text, They Do Not Replace It
Structure: Layout Tables and Reading Order
HTML emails are still built with nested tables to this day, because many mail programs do not render modern CSS layouts reliably. That is technically legitimate but becomes a barrier when a pure layout table is treated like a data table. A screen reader then announces rows and columns that have no meaning, and the reading order falls apart. The remedy is the marker role=presentation (or role=none), which signals to assistive technology: this table serves only for arrangement.
| Aspect | Layout table | Genuine data table |
|---|---|---|
| Purpose | Arranges blocks visually | Relates rows and columns to each other |
| Role | role=presentation, so silent | Announced as a table with header cells |
| Header cells | No th elements needed | th with scope for row and column |
| Screen reader | Reads the content in order | Names the heading for each cell |
Equally important is the order in the source code, because screen readers read the code, not the visual layout. What a table places side by side is read out one after another; if the source order does not match the logical reading order, chaos results. A single-column, linear layout is therefore not only mobile-friendly but also the most robust basis for a correct reading order. Where an email carries genuine data, such as an invoice breakdown, the rules for accessible data tables and complex content apply.
A Layout Table Is Not a Data Table
Contrast, Font Size and Dark Mode
Three visual factors decide whether an email stays readable: contrast, font size and behavior in dark mode. For normal text, WCAG 2.1 requires a contrast ratio of at least 4.5:1 (W3C, WCAG 2.1); for large text, from 24 pixels or 18 points (W3C, WCAG 2.1) or 14 points bold, 3:1 (W3C, WCAG 2.1) is enough. These values are measurable and belong in the template as fixed tokens. Pale buttons and light grey footers are the most common contrast errors in emails.
Contrast at Least 4.5:1
Text on the background reaches 4.5:1, large headings 3:1. Thin grey tones in the footer and pale calls to action are the typical outliers (WCAG 1.4.3).
Font Large Enough
Body text from around 14 to 16 pixels stays readable on small displays. Font that is too small is automatically scaled by some mobile clients and breaks the layout.
Robust in Dark Mode
Many clients recolor emails automatically. Transparent logos with a suitable outline and tested color pairs prevent text from disappearing in dark mode.
Dark Mode Is No Longer a Special Case
Anchoring Accessible Templates in the Team
A single tested email is of little use if the next campaign repeats the old mistakes. Sustainable accessibility in email marketing arises in two places: in tested master templates and in the minds of the team that fills them every day. Anyone who considers accessibility from the outset saves the expensive rework; this principle of accessibility by design applies to emails just as much as to websites.
- Harden the master template: Set up the lang attribute, semantic headings, role=presentation on layout tables and contrast tokens cleanly once.
- Enforce real text: Design the editor and approval process so no one accidentally sends a pure image email.
- Make alt text mandatory: No content-bearing image without a description, decorative images deliberately with an empty alt attribute.
- Test in light and dark mode: Check every template in several clients and both color modes before going live.
- Train the editorial team: The team understands the rules and applies them independently, instead of laboriously fixing them later.
- Monitor continuously: Recheck new templates and tool updates regularly so that no barrier returns.
The most effective lever is the editorial team itself. Tools find barriers, but only people who know what matters can avoid them. That is why we combine tested templates with a training for the marketing team that turns abstract criteria into concrete routines, from alt text to the dark-mode check. How accessible editorial work can be organized is shown in our article on training the editorial team. A WCAG audit captures the status, assesses the templates and embeds them in our accessible implementation, while ongoing BFSG monitoring reports when a template update introduces a new barrier.
Accessibility in email is rarely a question of grand technology, but of small habits: declare the language, describe the image, check the contrast, every time.
Sources and Studies