Accessible Email HTML
Email clients force you into the nested-table, inline-CSS layouts the web spent twenty years escaping. So the real work of email accessibility is making that table soup read as a clean linear document: layout tables marked so assistive technology ignores them, real semantic content inside them, a language the email forgets to declare, and alt text that survives the many clients that block images. This guide covers all of it end to end, mapped to WCAG 2.2, with copy-ready HTML.
Why Email Is Its Own Accessibility Problem
Everything you know about building an accessible web page still matters in email, but the ground rules change underneath it. Email is not rendered by a browser. Outlook on Windows uses Microsoft Word’s rendering engine. Other clients strip the <head>, drop <style> blocks, ignore flexbox, grid, positioning, and float, refuse external stylesheets, and run no JavaScript at all. To render the same in that whole zoo of clients, the entire email industry settled decades ago on one layout method: nested <table> elements with every style written inline.
That creates a direct collision with web accessibility. Tables on the web are for data, and using them purely for layout is a long-standing anti-pattern, because a screen reader announces every table as a grid of rows and columns. In email you have no choice but to lay out with tables. So the defining move of email accessibility is not to avoid the tables, it is to tell assistive technology to ignore them, so the message reads as the linear document it really is.
The reframe that decides everything
An accessible email is a linear document wearing a table costume. Your job is to make a screen reader read straight down the content, one heading, paragraph, image, and link after another, and never announce the scaffolding that positions it. That single goal drives almost every technique in this guide: mark the layout tables as presentational, keep the content inside them genuinely semantic, and make sure the source order is the reading order.
This is not a niche concern. Email reaches people at the moments that matter most, the order confirmation, the password reset, the appointment reminder, the invoice. And it is squarely within legal scope: where an organization is covered by the ADA, Section 508, or the European Accessibility Act, its emails carry the same obligations as its website. An inaccessible receipt is not a smaller problem than an inaccessible checkout page; it is the same problem, delivered to the inbox.
The rest of this guide works through the email-specific techniques in order, starting with the one that carries the most weight: making the layout tables disappear from the accessibility tree.
How Email Accessibility Maps to WCAG 2.2
The highlighted row, 1.1.1 Non-text Content, is the criterion email fails most often, because clients block images and the message ends up living in alt text that was never written. The rest are the criteria a well-built email must also satisfy, from declaring its language to holding contrast when a client force-inverts to dark mode.
| Criterion | Level | How it applies to email |
|---|---|---|
| 1.1.1 Non-text Content | A | Every meaningful image needs alt text that carries its message, since clients block images by default; spacer and decorative images need an empty alt. |
| 1.3.1 Info and Relationships | A | Headings, lists, and paragraphs must be real elements; layout tables must carry role="presentation" so their grid is not announced as structure. |
| 1.3.2 Meaningful Sequence | A | Because tables drive layout, the source order must match the intended reading order; screen readers and mobile linearization follow the markup, not the visual grid. |
| 3.1.1 Language of Page | A | The email needs a lang attribute so the screen reader pronounces it correctly; email templates routinely ship without one. |
| 2.4.4 Link Purpose (In Context) | A | Link and button text must describe the destination or action; a list of "click here" links is unusable by screen reader. |
| 1.4.1 Use of Color | A | Links and calls to action must be distinguishable without relying on color alone; underline text links rather than only coloring them. |
| 1.4.3 Contrast (Minimum) | AA | Text, including text on colored backgrounds and on buttons, needs 4.5:1 (3:1 for large text), and must still meet it after a client force-inverts to dark mode. |
| 1.4.10 Reflow | AA | The email must reflow to a single readable column on a narrow screen, without forcing horizontal scrolling or pinch-zoom. |
| 4.1.2 Name, Role, Value | A | Links and buttons must expose a real name and role; a bulletproof button is a genuine anchor, and role="presentation" removes the misleading table role. |
Each criterion links to its full reference and interactive demo. The complete WCAG 2.2 criteria are one click away.
1. Layout Tables and role="presentation"
This is the single most important technique in the guide, and it is one line per table. Every <table> you use only to position content, which in a typical email is nearly all of them, must be marked as presentational so a screen reader ignores its rows and columns and reads the contents as ordinary text.
Without it, the reader hears the scaffolding. A two-column band holding a logo beside a headline gets announced as “table, two columns, row one of one, column one, image, column two, heading”, and a multi-row newsletter becomes a grid the user has to navigate cell by cell. Mark the table presentational and all of that vanishes; the logo and headline are simply read in order.
<!-- A layout table: role="presentation" removes it from the a11y tree -->
<table role="presentation" width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td>
<img src="logo.png" alt="Acme" width="120" height="40">
</td>
<td>
<h1 style="margin:0;font-size:24px;">Your order is confirmed</h1>
</td>
</tr>
</table>A few details make this reliable across clients:
- Put it on every layout table, including nested ones. Emails nest tables several levels deep; each layout table needs its own
role="presentation". Marking only the outer table still leaves the inner grids announced. - Keep the old presentational attributes too.
border="0",cellpadding="0", andcellspacing="0"are still worth setting for consistent rendering in older clients, alongside the role. role="presentation"androle="none"mean the same thing here. Both strip the table semantics.presentationhas the widest client and assistive-technology support, so prefer it for email.
The exception: a real data table keeps its semantics
If a table in your email genuinely presents data, an order summary with columns for item, quantity, and price, or a statement of charges, then it is a data table, not a layout table, and it must keep its real structure: a <caption>, header cells with <th scope="col">, and no role="presentation". The test is the same as on the web: is this table conveying relationships between rows and columns, or just positioning things? Data keeps its semantics; positioning gets presentation. The accessible data tables guide covers how to build that data table correctly.
2. Real Semantic Content Inside the Tables
Making the tables presentational solves the container. The content inside those cells still has to be real, meaningful HTML, because that is what a screen reader reads once the grid is out of the way. This is where most emails quietly fail 1.3.1 Info and Relationships: the design has a clear visual hierarchy, but it is built from styled <span> and <font> tags and double <br> line breaks, so none of that hierarchy exists in the markup.
<td>
<!-- Real heading, not a big bold span -->
<h1 style="margin:0 0 12px;font-size:24px;line-height:1.3;">
Your March statement is ready
</h1>
<!-- Real paragraph, not text separated by <br><br> -->
<p style="margin:0 0 16px;font-size:16px;line-height:1.5;">
Here is a summary of your account activity for March.
</p>
<!-- Real list, not a line of bullet characters -->
<ul style="margin:0 0 16px;padding-left:20px;font-size:16px;">
<li>3 payments received</li>
<li>1 payment due on April 15</li>
</ul>
</td>The rules are the same ones that make a web page navigable, and screen reader users lean on them just as heavily in an email:
- Use real headings. A screen reader user navigates an email heading by heading, so the main message should be an
<h1>and section titles should be<h2>and<h3>in order, never a bold<span>that only looks like a heading. - Use real paragraphs and lists. Wrap prose in
<p>and bulleted content in<ul>or<ol>. Two<br>tags look like a paragraph break but convey no structure, and a line starting with a bullet glyph is not a list. - Do not skip heading levels. Go from
<h1>to<h2>in order so the outline holds together, the same discipline covered in the headings and bypass-blocks guide.
You still write every style inline, because most clients drop a <style> block, but inline styles do not stop an element from being semantic. A <h1 style="..."> is still a heading to a screen reader, no matter how it is styled.
3. The lang Attribute and Email Document Basics
On the web you rarely forget the language, because your framework or CMS sets <html lang> for you. Email templates routinely ship without it, and the result is that a screen reader reads the whole message in its default voice, using the wrong pronunciation rules, which is genuinely hard to follow. Setting the language is a one-attribute fix for 3.1.1 Language of Page:
<!DOCTYPE html>
<html lang="en" xmlns:v="urn:schemas-microsoft-com:vml">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
<title>Your order is confirmed</title>
</head>
<body>
<!-- email content -->
</body>
</html>A few document-level basics belong here too:
- Declare the character set.
<meta charset="utf-8">stops smart quotes and accented characters from turning into garbled symbols that a screen reader then reads aloud. - Give it a real
<title>. The title is used by the “view in browser” version and by some assistive setups, so make it describe the email rather than leaving it empty or generic. - Mark a change of language in part of the email. If a mostly-English email includes a paragraph in another language, wrap it in an element with its own
langattribute so that passage is pronounced correctly (3.1.2 Language of Parts).
4. Images, Alt Text, and Blocked Images
Images are the area email fails most, and the reason is unique to the medium: a large share of clients block images by default. Outlook, Gmail with images turned off, and many corporate gateways show your alt text in place of the image until the reader chooses to load it. So the alt text is not just for screen reader users; it is frequently the only thing anyone sees. That reframes 1.1.1 Non-text Content from a checkbox into a core content decision.
Never build the whole email as one image
The most damaging email pattern is a single sliced graphic with all the text baked into it and no live HTML. In an images-off inbox it renders as a blank rectangle, a screen reader finds nothing to read, and the text inside it also fails 1.4.5 Images of Text and cannot reflow or resize. Build the message from live text. Use images only for content that is genuinely a picture.
Alt text in email follows the same meaningful-versus-decorative split as the web, with one addition: you can style the alt text so that, when the image is blocked, the fallback still looks intentional.
<!-- Meaningful image: alt carries the message -->
<img src="hero.png" alt="Summer sale, up to 40% off shoes"
width="600" style="display:block;font-size:16px;color:#1f2937;">
<!-- Decorative or spacer image: empty alt so it is skipped -->
<img src="spacer.gif" alt="" width="1" height="20"
style="display:block;">
<!-- Logo: the brand name, not "logo" -->
<img src="logo.png" alt="Acme" width="120" height="40"
style="display:block;">- Meaningful images get descriptive alt. Describe what the image communicates, not that it is an image. A promotional banner’s alt should say the offer.
- Decorative and spacer images get
alt="". An empty alt attribute tells assistive technology to skip the image. A missing alt attribute is different: many clients then read the file name aloud. And never usealt="spacer". - Style the alt text. Setting
font-sizeandcoloron the<img>controls how the alt text looks when the image is blocked, so a broken-image fallback still reads cleanly rather than as tiny default text. - Background images need a real fallback. Always set a solid
background-colorbehind a background image and keep the important text as live HTML on top, so the content survives when the background does not load (in Outlook this is the VML background technique).
5. Bulletproof Buttons and Descriptive Links
The call to action is the whole point of most marketing and transactional email, and it is easy to build in a way that excludes people. The accessible pattern is a bulletproof button: a real <a>element styled with padding and a background color, so it is a genuine link with a name and a role, it is reachable and operable, and it renders as a styled button even when images are off. For Outlook on Windows you wrap the same link in a VML roundrect so the shape and fill render in Word’s engine too.
<!-- Bulletproof button: a real link, styled, with a VML fallback for Outlook -->
<table role="presentation" border="0" cellpadding="0" cellspacing="0">
<tr>
<td align="center" bgcolor="#1d4ed8" style="border-radius:6px;">
<!--[if mso]>
<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml"
href="https://acme.example/confirm"
style="height:44px;v-text-anchor:middle;width:220px;"
arcsize="14%" fillcolor="#1d4ed8" strokecolor="#1d4ed8">
<center style="color:#ffffff;font-family:sans-serif;font-size:16px;">
Confirm your order
</center>
</v:roundrect>
<![endif]-->
<!--[if !mso]><!-->
<a href="https://acme.example/confirm"
style="display:inline-block;padding:12px 28px;font-size:16px;
color:#ffffff;text-decoration:none;font-family:sans-serif;">
Confirm your order
</a>
<!--<![endif]-->
</td>
</tr>
</table>Two things separate an accessible CTA from an inaccessible one:
- It is a link, never an image or an onclick. An image of a button disappears when images are blocked. A
<div>or<td>with a JavaScriptonclickdoes nothing at all, because clients run no JavaScript, and it has no link role, no keyboard operability, and no accessible name. Only a real<a href>is a working, accessible button (4.1.2). - The text says what it does.
Confirm your orderorDownload your invoicetells a screen reader user exactly where the link goes. 2.4.4 Link Purpose is failed by a page or email full ofClick hereandRead morelinks that are meaningless in the screen reader’s list of links.
For text links in body copy, do not rely on color alone to mark them, which fails 1.4.1 Use of Color. Underline them, so a reader who does not perceive the link color can still tell text from link. And when you have several “Read the article” style links, give each one distinguishing text, for example the article’s title, so they are not identical out of context.
6. Reading Order and Single-Column Reflow
Because tables control the layout, the order the content appears in the markup is the order a screen reader reads it, and the order most email clients use when they linearize the layout into a single column on a phone. If you use table cells to place something visually before content that comes earlier in the source, the read order and the visual order diverge, which fails 1.3.2 Meaningful Sequence. The rule is simple: write the content in the order it should be read, and let the layout follow, not the other way around.
The other half of this section is reflow. An email that forces horizontal scrolling or pinch-zoom on a phone fails 1.4.10 Reflow and is miserable for everyone. The practical constraints:
- Cap the width and go single-column on mobile. Keep the main container around 600px wide, and let multi-column bands stack into one column on narrow screens so nothing requires sideways scrolling.
- Do not depend on media queries alone. Some clients, historically including parts of Gmail, ignore
@mediarules, so a robust email uses a fluid or hybrid layout (percentage widths withmax-widthcaps) that reflows even without the media query, and treats the media query as an enhancement. - Keep body text at a readable size. Use a base font size of at least 14 to 16px. Tiny type is a common email failing and hurts low-vision readers most.
- Give buttons room to be tapped. On a touch screen the tappable area of a button and of adjacent links should be large enough to hit reliably, comfortably above a 44px target.
7. Color, Contrast, and Dark Mode
Email leans heavily on colored backgrounds, tinted bands, and filled buttons, so contrast needs deliberate attention. 1.4.3 Contrast (Minimum) asks for 4.5:1 for normal text and 3:1 for large text, measured against the actual background behind it. The place teams miss it is button label against button fill, and body text sitting on a colored section rather than on white.
Then there is dark mode, which is harder in email than anywhere else. There is no single behavior. Some clients respect prefers-color-scheme. Others, including Outlook.com and some Gmail apps, force-invert your colors whether you ask for it or not, and partial-invert clients may recolor some elements and not others. Forced inversion can quietly break contrast, and a dark logo on a transparent background can vanish the moment the backdrop becomes dark. A workable strategy:
- Declare your color-scheme support. The
color-schemeandsupported-color-schemesmeta tags, plus acolor-schemestyle on key elements, tell clients that respect them to use your dark styles instead of a blunt inversion. - Avoid pure black and pure white. Extremes invert most aggressively. Slightly off-black text and off-white backgrounds tend to survive inversion with their contrast closer to intact.
- Protect logos and dark artwork. Give a dark logo a small padded light background or an outline so it does not disappear on an inverted dark backdrop.
- Never signal with color alone. Inversion can swap the very colors you used to mean something, so follow 1.4.1 and back color up with text, an underline, or an icon.
The only way to know is to look: open the email in a force-inverting client and confirm the text still meets contrast and nothing has disappeared.
8. The Preheader and the Plain-Text Alternative
Two small pieces of an email do quiet accessibility work that is easy to skip. The first is the preheader, the short preview line the inbox shows after the subject. In the HTML it is a visually hidden element at the very top of the body, and because a screen reader reads it as the first content of the message, it should be a real, useful summary, not an afterthought.
<body>
<!-- Preheader: shown in the inbox preview, read first by a screen reader -->
<div style="display:none;max-height:0;overflow:hidden;mso-hide:all;">
Your order #2041 is confirmed and ships tomorrow.
<!-- Spacer entities keep body text from spilling into the preview -->
‌ ‌ ‌ ‌
</div>
<!-- visible email content follows -->
</body>Get two things right. Make the preheader a genuine summary, because an empty one lets the client pull in whatever text comes first, often a “view in browser” URL or an image alt string, which reads as noise both in the inbox and to a screen reader. And hide the trailing spacer characters, the zero-width non-joiner and non-breaking space entities that stop body text from spilling into the preview, inside the same hidden container so they are not announced.
The second piece is the plain-text alternative. A well-formed email is sent as multipart/alternative, with an HTML part and a real text/plainpart. That plain-text version is a deliverability signal, but it is also an accessibility and robustness feature: it is what some setups, minimal clients, and users who prefer plain text actually read. Make it mirror the content of the HTML email, with the real links written out, not a stub that only says “view this email in your browser.” Offer that browser view as well, as a genuine fallback, but do not let it be the only readable form of the message.
9. Testing an Accessible Email
You cannot fully test an email the way you test a web page, because the same source renders differently in every client and an automated checker only sees the source, not the rendered result. Test in layers, from cheapest to most revealing.
Validate the source
Before sending anything, check the HTML for the fundamentals: a lang attribute, role="presentation" on every layout table, an alt attribute on every image (empty for decorative ones), real heading elements in order, and descriptive link text. Email-focused platforms such as Litmus and Email on Acid now include accessibility checks that flag several of these automatically.
Send real test emails
Send the email to yourself and open it in the clients your audience actually uses. Outlook on Windows, Gmail on the web and in its apps, and Apple Mail on macOS and iOS render very differently, so a design that reads well in one can break in another. Then turn images off and confirm the message still makes complete sense from the live text and alt text alone.
Run a screen reader on the rendered email
This is the test that proves the linear read works. Open the delivered email and listen to it with a screen reader: VoiceOver in Apple Mail on macOS or iOS, NVDA reading the email in Outlook or a browser view, or TalkBack in Gmail on Android. Confirm it reads straight down the content with no layout-grid announcements, that headings let you jump through the email, and that the links make sense in the links list.
Check mobile and dark mode
On a phone, confirm the layout reflows to a single column with comfortable tap targets and readable text size, and open the email once in a force-inverting dark-mode client to confirm contrast survives. For where this fits in a wider process, see the accessibility audit guide and the automated versus manual testing guide, which explains why the manual pass is the one that catches what matters here.
Common Email Accessibility Mistakes & How to Fix Them
These are the errors that turn up most in real email audits. Every one is a small decision with an outsized effect on whether the message reaches everyone who receives it.
| Anti-pattern | Why it fails | The fix |
|---|---|---|
| The entire email is one big sliced image with no live text. | Clients that block images by default show a blank rectangle, and a screen reader has nothing to read, so the whole message is lost (fails 1.1.1 and 1.4.5). | Build the email from live HTML text. Use images only for content that is genuinely visual, and give each one alt text that carries its meaning. |
| Layout tables with no role="presentation". | A screen reader announces the positioning grid as data, reading out rows and columns, which turns a short message into a confusing table to navigate (fails 1.3.1). | Add role="presentation" to every table used only for layout, so assistive technology reads the cell contents as a normal linear flow. |
| No lang attribute on the html element. | The screen reader falls back to its default voice and pronounces the content with the wrong language rules, which is hard to follow (fails 3.1.1). | Set the language on the root element, for example a lang value of "en", matching the language the email is written in. |
| Spacer and decorative images with a missing alt attribute or alt="spacer". | The screen reader announces the file name or the word spacer for images that carry no meaning, cluttering the read with noise. | Give every decorative or spacer image an empty alt attribute (alt="") so assistive technology skips it entirely. |
| The call to action is an image of a button, or a div or cell with an onclick. | A blocked image leaves no visible or readable CTA, and an onclick element has no link role, no keyboard operability, and does nothing because email clients run no JavaScript (fails 1.1.1, 2.1.1, and 4.1.2). | Use a real anchor styled as a bulletproof button, with descriptive text and, for Outlook, a VML roundrect fallback around the same link. |
| "Click here" or "Read more" repeated as link text. | A screen reader user pulling up the list of links hears a wall of identical, meaningless labels and cannot tell where any of them lead (fails 2.4.4). | Write link text that names the destination or action, so each link makes sense read on its own, out of the surrounding sentence. |
The Accessible Email Checklist
- Live text, not images of text. The message is built from real HTML text; images carry only genuinely visual content, and the email is never one big graphic.
- Layout tables are presentational. Every table used for positioning carries
role="presentation"; only genuine data tables keepth,scope, and a caption. - The language is declared.
<html lang="...">is set so the screen reader pronounces the content correctly. - Structure is real. Headings (a single
<h1>, logical order), paragraphs, and lists are real elements, not styled spans or double line breaks. - Images are described or emptied. Meaningful images have descriptive alt; spacer and decorative images have
alt=""so they are skipped. - CTAs are real links. Buttons are bulletproof
<a>elements with descriptive text, not images of buttons or onclick elements. - Links make sense out of context. No “click here”; link text names the destination, and body links are underlined, not color-only.
- Reading order equals source order. The markup order matches the intended reading order, and the email reflows to a single column on mobile.
- Contrast holds in light and dark. Text meets 4.5:1 on its background, buttons included, and survives a force-inverting dark-mode client.
- A real preheader and plain-text part. The preheader summarizes the email, and a genuine
text/plainalternative mirrors the content.
Get the Foundations Right
Email accessibility rests on two techniques the rest of the web uses too: correct alt text, and knowing when a table is data versus layout. Start there.
Frequently Asked Questions
Do accessibility rules like WCAG and the ADA apply to email?▾
Yes. An email is content an organization publishes and sends, and where that organization is covered by the ADA, Section 508, or the European Accessibility Act, its transactional and marketing emails fall within the same accessibility obligations as its website. WCAG 2.2 is the practical standard those laws point to, and its success criteria map cleanly onto email. Even setting law aside, an inaccessible email quietly loses real customers: a blind subscriber who cannot read your receipt, or a low-vision reader who cannot make out pale text on a colored button, simply does not act on the message. Accessibility in email is both a compliance question and a conversion one.
Why do accessible emails still use table layouts when the web abandoned them?▾
Because email clients are far behind browsers. Outlook on Windows renders with Microsoft Word's engine, not a browser engine, and many clients strip out or ignore modern CSS layout such as flexbox, grid, floats, and positioning, external stylesheets, and JavaScript entirely. Nested tables with inline CSS are the only layout method that renders consistently across the whole range of clients. The accessibility answer is not to rip the tables out, which would break the email everywhere, but to mark every layout table with role="presentation" so assistive technology ignores the grid and reads the content as a normal linear flow of text.
What does role="presentation" do on an email table?▾
It removes the table's grid semantics from the accessibility tree. Without it, a screen reader announces a layout scaffold as data: "table, three columns, row two of eight, column one," for markup that only exists to position a logo next to a headline. That turns a simple message into a navigation puzzle. With role="presentation" on the table, the screen reader ignores the rows and cells and reads the contents in source order as ordinary text. Put it on every table used purely for layout. The one exception is a table that genuinely presents data, such as an order summary or a receipt: that table keeps its real semantics, with th, scope, and a caption, exactly as a data table on the web would.
Why does alt text matter even more in email than on the web?▾
Because a large share of email clients block images by default. Outlook, Gmail with images turned off, and many corporate email gateways show the alt text in place of the image until the reader chooses to load it, so the alt text is frequently the only thing anyone sees, sighted or not. The worst case is an email built as one big sliced image with no live text: in an images-off inbox it renders as a blank rectangle, and a screen reader has nothing to read. Write alt text that carries the actual message for meaningful images, and give spacer and purely decorative images an empty alt attribute (alt="") so they are skipped rather than announced by file name.
How do I build an accessible email button?▾
Use a real anchor element styled with padding and a background color, the pattern the email industry calls a bulletproof button, so it is a genuine link with an accessible name and a link role, reachable and operable, and it still renders as a styled call to action when images are switched off. For Outlook on Windows you wrap the same link in a VML roundrect so the rounded shape and fill render in Word's engine too. What you must not use is an image of a button, which disappears the moment images are blocked, or a div or table cell with a JavaScript onclick, because email clients do not run JavaScript and such an element has no link role, no keyboard operability, and no accessible name. The visible link text should describe the action, for example "Confirm your order" rather than "Click here."
What is preheader text and how do I make it accessible?▾
The preheader is the short preview line an inbox shows after the subject. In the HTML it is a visually hidden element placed at the very top of the body. Make it a real, useful summary of the email, because if you leave it empty the client pulls in whatever text comes first, often a "view in browser" URL or an image alt string, which reads as noise. A screen reader announces the preheader as the first content of the message, so a clear one also orients the user before the layout begins. Hide the trailing spacer characters that stop the client from spilling body text into the preview, using zero-width and non-breaking space entities inside the same hidden container, so they are not read aloud.
Does dark mode break accessible emails?▾
It can, and email dark mode is genuinely harder than web dark mode. Some clients respect the prefers-color-scheme media query, but others, including Outlook.com and some Gmail apps, force-invert your colors regardless of your CSS. Forced inversion can drop text below the required contrast, or turn a dark logo invisible against a background that just became dark. Declare your intent with the color-scheme and supported-color-schemes meta tags, avoid pure black and pure white extremes that invert most violently, give logos a small padded or outlined background so they survive an inverted backdrop, and always test in a force-inverting client to confirm text contrast holds in both modes rather than assuming your light-mode design carries over.
How do I test whether an email is accessible?▾
Do not rely on an automated checker alone; an email is only truly testable once a real client has rendered it. Work in layers. First validate the source for alt attributes, role="presentation" on layout tables, a lang attribute, and a sound heading structure. Then send real test messages and open them in the major clients, since Outlook, Gmail, and Apple Mail each render differently. Turn images off and confirm the message still makes sense. Run a screen reader on the rendered email, VoiceOver in Apple Mail on macOS or iOS, NVDA reading an email in Outlook or a browser, TalkBack in Gmail on Android, and listen to the linear read. On a phone, confirm the layout reflows to a single column with comfortable tap targets, and open the email once in a force-inverting dark-mode client to check contrast.
Essential Accessibility Resources
Comprehensive tools, checklists, and guides to help you create inclusive digital experiences