Email accessibility

An accessible HTML email is one that a screen-reader user can follow, that still makes sense with images turned off, and that stays readable on a 320-pixel phone screen and in dark mode. I build new newsletter and notification templates and fix the ones you already send: layout tables marked as presentation, real headings, alt text, live text instead of text in images, contrast, link texts that say where they lead, a declared language, dark-mode styles and a plain-text part, well under the size at which Gmail clips a message. You receive HTML to import into your sending tool, with axe-core reports and a plain list of what the checks did not cover.

This page is for you if one of these describes your situation:

• You run an online shop selling to consumers in the EU, and your newsletters and order e-mails are part of your European Accessibility Act work.
• Your designer delivers each newsletter as one large picture, with the discount, the code and the end date inside it.
• You are an agency building templates in Mailchimp, Klaviyo or Brevo for clients, and a client or a tender asks for WCAG AA.
• Your e-mails scroll sideways on phones or become unreadable in dark mode, and you want to know why before paying for a redesign.

• Images off: turn off automatic images in your mail program (in Gmail on the web: Settings → See all settings → General → Images) and open your last campaign. Can you still read the offer, the code and the end date?
• Link texts: read only the links. “Click here” and “More” tell a screen-reader user, who often moves from link to link, nothing.
• Phone: if you have to scroll sideways, the layout has a fixed width.
• Size: “[Message clipped] View entire message” at the end of a Gmail message means the HTML is too large, and what follows, often the unsubscribe link, is hidden.

Read on for the technical detail. Below: what makes an HTML email accessible, a measured before-and-after example on a fictional shop newsletter with every file downloadable, and the rules for selling into the EU. To skip ahead, forward me one newsletter and I will tell you what is wrong with it.

An accessible email carries its message in live, structured HTML text rather than in pictures and styling, because email clients block images, strip CSS and wrap your message inside their own page.

E-mails still use tables for layout, because Outlook on Windows renders HTML with the Word engine. A layout table without role="presentation" can be announced as a data table, with rows and columns that mean nothing; marked as presentation, the grid is skipped and only the content is read.

A table cell styled to look like a heading cannot be reached by heading navigation. Real h1–h3 elements let readers move through a newsletter section by section, also in webmail. When columns stack on a phone, source order becomes reading order, so the source is written in the order the message should be read.

Many mail programs block images until the reader allows them. If the discount, the code and the date exist only in a picture, the reader sees an empty box and a screen reader announces nothing useful. Informative images need alt text that says what they show (WCAG 2.2, 1.1.1); decorative ones get alt="" so that they are skipped. Buttons are styled links with a VML fallback for Outlook, not pictures of buttons.

Text needs a contrast of at least 4.5:1 against its background, or 3:1 for large text (WCAG 2.2, 1.4.3); light grey footers at 9 or 10 pixels are where newsletters fail most visibly. Link texts say where they lead, such as “View the ceramic mug” or “Unsubscribe”, so that a list of links makes sense on its own (WCAG 2.2, 2.4.4).

I set lang and dir on the <html> element and again on the message wrapper, because webmail clients often drop the <html> element. A <title> and a preheader give the message a name and a preview line. Dark mode needs its own palette: some apps follow prefers-color-scheme styles, others invert colours on their own. A plain-text part in a multipart/alternative message serves readers and programs that do not show HTML, and a one-click List-Unsubscribe header (RFC 8058) lets the mail program show its own unsubscribe button. Gmail clips messages whose HTML exceeds about 102 KB.

This is a measured worked example on a fictional newsletter, not client work. I built a typical image-heavy campaign e-mail, measured it, rebuilt it accessibly and measured it again in headless Chromium. No real email client and no screen reader were used; the limits are listed below. All files can be downloaded.

• Content: everything is fictional. The newsletter is for a made-up Turkish shop, “Örnek Mağaza — Ekim kampanyası” (an October campaign), written in Turkish. The shop, its address, products, prices, the code EKIM40 and the reserved, non-resolving domain ornek-magaza.example do not exist. Both footers say so, and the .eml carries an X-Example-Notice header.
• Images: simple shapes I drew; the social icons are generic letter circles, not brand logos. No third-party content is used, and the files may be reused as examples.
• Tools: axe-core 4.13.0, run with the tags wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22a and wcag22aa, in Chromium 141.0.7390.37 (headless, driven by Playwright 1.56.0). Alongside it, my own audit script for colour pairs, font sizes, alt text, links, tables, images off, a 320-pixel viewport and emulated dark mode.

The newsletter text is Turkish; the reports and evidence images are in English.

Before, axe also listed one item for manual review (bypass); after, none. Of its best-practice rules, which are not WCAG requirements, landmark-one-main and region still appear after the rebuild. I left them on purpose: the mail program wraps the message in its own page and landmarks, so a <main> element inside the e-mail does not help. The rebuilt message uses role="article" with an aria-label instead.

Full contrast tables for light and dark mode, with every colour pair, are in the axe summary inside the ZIP.

• The offer: it existed only inside a 600×300 image without alt text. It is now live text on a solid #7c2d12 background; the hero image above it is decorative (alt="").
• Button and images: the image button became a styled link in a presentation table, with a VML v:roundrect fallback for Outlook. The logo link reads “Örnek Mağaza ana sayfa” (home page), products have descriptive alt text, and the social icons are decorative next to visible link text.
• Links: “Buraya tıklayın” (click here) and “Devamı” (more) became texts such as “Seramik kupayı inceleyin” (view the ceramic mug) and “Abonelikten çıkın” (unsubscribe).
• Colour, size and structure: 16 px body text in #1f2937, #4b5563 and #9a3412; h1 to h3; lang="tr" dir="ltr", a title and a preheader; a fluid container with a 600 px maximum whose columns stack at 620 px and below.
• Dark mode and the message: color-scheme meta tags, a prefers-color-scheme: dark palette, [data-ogsc] overrides and a white plate behind the logo; a plain-text part in a multipart/alternative .eml with List-Unsubscribe and one-click headers.

No screen reader was used (NVDA, JAWS, VoiceOver, TalkBack); axe checks the code, not what a screen reader announces inside webmail. No automated check judges whether alt text is good, whether the reading order makes sense or whether the language is plain; I reviewed those by hand. My contrast script cannot measure text in or over images. The size is the raw file; sending tools add tracking, so the real margin under Gmail’s limit is smaller. Deliverability, authentication and legal checks were not part of the example.

The HTML, .eml, plain-text and JSON files are available only inside the ZIP.

You receive an HTML template ready to import, its plain-text version, and reports that show what was measured and what was not.

• The accessible HTML template, with the merge tags or template variables of your existing version kept in place.
• A plain-text version and a preheader text, for your approval.
• Before-and-after axe-core reports, contrast tables for light and dark mode, and screenshots at desktop width, at 320 px, with images off and in emulated dark mode.
• A findings report, including what was left alone on purpose and what the checks cannot see, plus a one-page note for whoever writes your next campaigns.

Mailchimp, Klaviyo and Brevo accept your own HTML as a custom template; Shopify notifications are edited as code in the shop admin, and WooCommerce e-mails through template overrides in your theme. You or your developer import the HTML and send a test to yourself; I correct what comes back wrong. If you have an account with an email testing tool such as Litmus or Email on Acid, I can review its client screenshots as an optional step; without one, the report states this as a limit.

You send one real e-mail first; the price is fixed before any work starts.

1. Forward one newsletter, or send its HTML export. The campaign or order e-mail that worries you most. I tell you what is actually wrong, including the parts not worth paying to fix.
2. You receive a scope and a fixed price for that template or the whole set.
3. I do the work. You receive a preview, marked as such, with the axe-core report, the screenshots and a list of any colour or wording changes for your approval.
4. Your approval releases the final files: the HTML, the plain-text version and the findings report.

I price each job after seeing the material. The number of e-mails alone does not decide the effort: one modular master template that all your campaigns reuse can take less time than three one-off newsletters built from images. You get a fixed price for the set before work starts, with no hourly meter. If your campaigns share one template, fixing that template is usually the cheaper route, and I will say so.

Since 28 June 2025, e-commerce services offered to consumers in the EU fall under the European Accessibility Act. Whether, and how far, that reaches your newsletters and order e-mails is a legal question.

Legal note: this page covers the technical side. Whether the law applies to your shop, and to which of your e-mails, is for your legal adviser to confirm.

• The European Accessibility Act, Directive (EU) 2019/882, covers e-commerce services, and member states apply their national laws from 28 June 2025. Germany’s Barrierefreiheitsstärkungsgesetz (BFSG) names “Dienstleistungen im elektronischen Geschäftsverkehr” in § 1(3) No. 5. The directive describes these services through websites and mobile apps; it does not list e-mail as a separate channel.
• Article 4(5) of the directive exempts microenterprises that provide services. Whether that applies to you is for your lawyer to decide.
• The technical yardstick used in practice is WCAG 2.2, Level AA. It is written for web content; HTML e-mail uses the same technologies.

Shops outside the EU, in Türkiye, the UK or the US, meet these rules through their sales to EU consumers. And without any law, an offer the reader cannot see with images blocked, on a phone or in dark mode does not sell.

These tools accept custom HTML templates, and I write the HTML for that. I have not tested imports into specific platforms, so you or your developer import it and send a test; I keep your merge tags and correct what the import breaks.

Not in the worked example: it was measured in headless Chromium only, and I say so. If you have an account with an email testing tool, I can review its client screenshots as an optional step. Otherwise, real-client rendering stays a stated limit in the report.

No, and I do not claim otherwise. My findings come from the code, the standards, axe-core and manual review. Testing by people who use assistive technology should be commissioned separately.

That is the main thing to stop. In the example, a reader with images blocked could read 0 of the 6 offer facts before and 6 of 6 after. Images can stay as decoration or product photos; the offer itself belongs in live text.

Accessible code adds some weight, but not much. In the example the HTML grew from 5,543 to 12,137 bytes, far below Gmail’s clipping point of about 102 KB. Sending tools add tracking code, so I measure the size of your real export as well.

That is a legal question, and your lawyer decides it. The directive covers e-commerce services and describes them through websites and apps, without listing e-mail separately. I build to WCAG 2.2 AA either way and document what was checked.

• Multilingual PDF accessibility (PDF/UA)
• Alt text writing
• Accessible colour palette
• Accessible Word and PowerPoint
• Accessible charts and infographics
• Easy Read and plain language
• VPAT and Accessibility Conformance Report
• Custom-domain e-mail in Gmail

One e-mail — the campaign, order confirmation or template that worries you most. Forward it to me as it arrived. You get back a straight account of what is wrong with it, including the parts that are not worth paying to fix.

Ali Karabüyük · Tekirdağ, Türkiye · working remotely with clients worldwide · document and image production since 2004, professional practice since 2008.