How to Make Emails Accessible (Without Redesigning Everything)

Picture a subscriber who genuinely likes your emails. She opens one on her phone with the text size cranked up because her eyes are tired. Another subscriber hears your email read aloud by a screen reader on his commute. A third opens it in dark mode at midnight. If your email is a single giant image with tiny gray text baked in, all three of them just hit a wall — and quietly stopped being your readers.

So let’s talk about how to make emails accessible, because the short answer is wonderfully doable: use real, live text instead of images of text, give your email a logical structure with actual headings and lists, write alt text for every meaningful image, keep text contrast strong, never rely on color alone to convey meaning, use readable type sizes with breathing room, test in dark mode and with images off, and include a clean plain-text version. None of that requires a redesign. Most of it is template-level, which means you fix it once and every future send inherits the kindness.

Why does email accessibility matter — and who is it actually for?

Here’s the part nobody tells you: accessibility isn’t a niche concern for a tiny sliver of your list. A meaningful share of your subscribers read your emails with a screen reader, with text zoomed way up, in dark mode, with images turned off, on a cracked phone screen in bright sunlight, or while juggling low vision, color blindness, motor differences, or a brain that’s simply too tired to parse a dense wall of cleverness. Disability is also situational — a broken reading arm, a migraine, a loud train — which means everyone on your list benefits from an accessible email some of the time.

So this is the right thing to do, plainly. But it’s also the smart thing. An email that a screen reader can’t parse is an email that didn’t get read. An email that’s invisible with images off is an email that got deleted. Every accessibility fix you make is simultaneously a deliverability-of-meaning fix: more of the people you already paid to reach actually receive the message. Excluding readers you worked hard to earn is both unkind and bad business, and you never have to choose between the two framings — they point at the exact same to-do list.

One honest note before we dive in: I’m going to keep this qualitative on purpose. You’ll see articles quoting precise disability percentages, and the honest truth is those numbers vary wildly by audience, country, and how the question was asked. You don’t need a statistic to justify this work. You need the mental image of one real subscriber who couldn’t read what you sent.

What’s the single biggest email accessibility mistake?

The all-image email. One beautiful, designer-approved JPEG with every headline, paragraph, and button baked into the pixels. I understand the temptation — it renders “perfectly” everywhere, fonts and all. But to a screen reader, that email is either total silence or one awkward alt attribute trying to summarize an entire campaign. With images turned off (which plenty of email clients do by default), it’s an empty white rectangle with a sad little broken-image icon. Zoomed in, the text goes blurry instead of reflowing. In dark mode, it glows like a lightbox.

If you fix only one thing after reading this, fix this: your message lives in real, live HTML text, and images support it rather than replace it. Headlines are text. Body copy is text. Buttons are HTML buttons (a styled link with padding), not pictures of buttons. Images carry the things images are good at — product photos, illustrations, charts you also describe in words — and the words themselves stay words.

A good gut check: turn images off in your preview. If the email still makes its offer, states its value, and presents a tappable call to action, you’ve passed. If it’s a ghost town, the email was never really written — it was only painted.

How do you structure an email so screen readers can navigate it?

Screen-reader users rarely listen to an email top to bottom like an audiobook. They skim, exactly like sighted readers do — jumping between headings, pulling up a list of all the links, skipping past blocks that don’t interest them. Your job is to give that skimming something to grab onto.

Use real heading elements

Where your email builder supports it, make your section titles actual heading elements (h2, h3) rather than paragraphs that are merely bolded and enlarged. Visually they can look identical; structurally they’re night and day, because headings are the skeleton assistive tech navigates by. Keep the hierarchy logical — don’t jump from a top-level heading straight to a tiny sub-sub-heading just because the font size looked right.

Code lists as lists

If you’re listing three benefits, use a real ul with li items — not a paragraph with hyphens or emoji playing bullet-point dress-up. A real list announces itself (“list, three items”), which gives listeners a map of what’s coming. Fake lists are just run-on sentences with decorations.

Mind the reading order

Email layouts are usually built on tables, and screen readers read them in source order: left to right, top to bottom. Multi-column designs can read in a sequence that makes no sense aloud — a caption before its subject, a price before the product. Keep layouts simple, make sure the source order tells the story in the right sequence, and mark layout tables as presentational (role=”presentation”) where your tooling allows, so they aren’t announced as data tables. Set the email’s language attribute too, so screen readers pronounce your words with the right voice.

Write link text that stands alone

Because screen-reader users often navigate by pulling up a list of every link in the email, each link has to make sense stripped of its surroundings. A list that reads “click here, click here, learn more, here” is a locked door. A list that reads “Read the full onboarding guide, Browse the spring collection, Update your email preferences” is a menu. Descriptive links help sighted skimmers just as much — they’re the highlighted phrases everyone’s eyes jump to anyway.

How to make emails accessible with alt text that actually helps

Every meaningful image in your email needs alt text — the written stand-in that screen readers speak aloud and email clients display when images don’t load. The craft here is the same craft as writing good alt text anywhere: describe the content or function of the image, not its existence.

• Content images: say what matters about what’s shown. “Overhead photo of the weekender bag open, showing the laptop sleeve and two zip pockets” beats “bag photo” and infinitely beats “IMG_2047_final_v3.”
• Functional images: if the image is a link or does a job, the alt text names the job. A logo linking home is alt=”SocialBlaze home,” not a poetic description of the logo mark.
• Decorative images: the divider swooshes, the ambient background flourish — give these an empty alt attribute (alt=””). That’s not laziness; it’s an explicit signal that says “nothing to see here,” so the screen reader skips it instead of announcing a mysterious unnamed image. Missing alt and empty alt are different things — missing alt makes some screen readers read the file name aloud, which is nobody’s favorite poetry.

And a gentle repeat of the cardinal rule: alt text is a supplement, never a loophole. If you catch yourself writing three paragraphs of alt text to carry an image-of-text banner, the real fix is making that text live text.

What do color, contrast, and dark mode have to do with accessibility?

Contrast: can everyone actually read this?

Low-contrast text — pale gray on white, white on a light pastel — is the quiet villain of email design. It looks airy in the design tool and vanishes on a sun-glared phone or for anyone with low vision. Aim for strong contrast in the spirit of the WCAG guidelines: dark text on light backgrounds (or genuinely light on genuinely dark), with buttons whose label clearly pops against the button fill. Free contrast-checker tools will give you a pass/fail in seconds; make checking your text and button combinations a one-time template task.

Never let color carry meaning alone

This one’s subtle and it bites good designers constantly. “Items in red are sold out.” “Green means in stock.” “The highlighted dates are unavailable.” For a colorblind reader — or anyone whose email client remixed your palette — that information simply evaporates. The fix isn’t abandoning color; it’s never letting color work alone. Add the word (“Sold out”), an icon, a strikethrough, a label. Color becomes the garnish on information that’s already stated, and nobody is locked out of knowing what you meant.

Dark mode: the honest conversation

Okay, let’s be honest about dark mode: you don’t fully control it. Different email clients handle it differently — some leave your colors alone, some invert them, some apply partial transformations that can turn your carefully chosen palette into something you never approved. You can’t prevent all of it, but you can avoid the classic traps:

• The transparent-PNG logo trap: a dark logo on a transparent background disappears completely against a dark-mode background. A thin light outline or a padded background behind the logo keeps it visible in both worlds.
• Baked-in backgrounds: text shadows and effects that assume a white canvas can turn illegible when the canvas flips.
• Low-contrast accents: a color that barely passed on white may fail hard on near-black. Check your brand accents against dark backgrounds too.

The practical rule: preview every template in light and dark mode before it ships, and design with enough contrast headroom that a client’s transformation can’t push you into unreadable territory.

How should typography and motion treat your readers?

Typography kindness

Think of typography as hospitality. A few habits make everything you send easier on every pair of eyes:

• Readable sizes: roughly 14px and up for body text is a kind guideline (many designers go 16px for mobile comfort). Tiny legal-fine-print body copy forces zooming and squinting.
• Line spacing: give lines room to breathe — cramped leading turns paragraphs into bricks.
• Left-aligned body text: centered or justified paragraphs are genuinely harder to read at length; the eye loses its anchor at every line return. Center a headline if you like, but let body copy sit flush left.
• Short paragraphs: two to four sentences, with headings and lists breaking up the journey. Walls of text are a cognitive toll booth.
• Generous tap targets: buttons and links need enough padding that a thumb — or a hand with limited fine motor control — can hit them without three attempts. Space adjacent links apart so the wrong one doesn’t get tapped.

Motion restraint

Two rules here, one absolute and one judgment call. The absolute: no flashing or strobing content, ever. Rapidly flashing imagery can trigger seizures in photosensitive readers; there is no campaign concept that justifies that risk, full stop. The judgment call: animated GIFs are fine in moderation, but keep them gentle and slow, let them settle rather than loop frantically if you can, and never let the animation be the only place a key message lives — because plenty of clients and settings show only the first frame. If frame one doesn’t carry the point, the point is lost.

Does plain language count as accessibility? (Yes — here’s why)

Accessibility isn’t only about eyes and ears; it’s also about cognition. Your list includes people reading in their second language, people with dyslexia or ADHD, people who are exhausted, and people giving you exactly four seconds of attention between meetings. Plain language is the accessibility feature that serves every single one of them.

That means short sentences. Familiar words over impressive ones. One idea per paragraph. Front-loaded value — say the important thing first, then elaborate. Descriptive subject lines that honestly state what’s inside (“Your March schedule template is ready”) instead of riddles the reader must open to solve. Clever is lovely; clear is mandatory; and when they fight, clear wins.

Structure helps cognition too, which is why a well-organized roundup is easier on tired brains than a stream of consciousness — if you send recap-style emails, the scannable format covered in our guide to writing a digest email people actually read is quietly an accessibility pattern: clear sections, descriptive links, predictable rhythm.

And then there’s the plain-text part, which is the most literal accessibility feature in email: send multipart emails that include a clean, genuinely readable text version alongside your HTML. Some readers choose plain text; some devices and clients fall back to it; some assistive setups prefer it. Auto-generated text parts are often a soup of URLs and leftover markup, so it’s worth learning to shape yours deliberately — our walkthrough on how to write a plain-text email covers exactly how to make that version a pleasure instead of an afterthought.

How do you test whether your emails are accessible?

You don’t need a lab or a budget. You need a short ritual and a little humility. Here’s a quick-test workflow that takes about ten minutes the first time and five once it’s habit:

1. Images-off pass. Turn images off in your preview or client. Can you still tell what the email offers and where to click? Do the alt texts read like a coherent skeleton of the message?
2. Zoom pass. Blow the email up to roughly double size on your phone. Does text reflow and stay readable, or does the layout shatter? Are buttons still easy to hit?
3. Dark-mode pass. View it in a dark-mode client. Logo still visible? Text still readable? Any accent colors gone muddy?
4. Screen-reader spot-check. Use the free screen reader already on your machine — VoiceOver on a Mac or iPhone, NVDA on Windows — and listen to the email top to bottom once. You will learn more in three minutes of listening than in an hour of reading about accessibility. Notice the reading order, the link announcements, what gets skipped, what gets mangled.
5. Link-list pass. Read every link’s text out of context. Would each one make sense on its own in a list? Rename any “click here” stragglers.
6. Checker pass, honestly weighted. Run an automated accessibility checker if your email platform offers one. Here’s the honest framing: checkers are great at catching mechanical issues — missing alt attributes, missing language settings, some contrast failures — and blind to judgment issues like whether your alt text is useful, whether your reading order tells the story, or whether your link text means anything. Treat a passing grade as “no obvious mechanical problems,” never as “accessible.” The listening test is the real exam.

You don’t have to run all six on every single send. Do the full workflow when a template changes; do passes one, three, and five as a quick pre-send check.

How do you retrofit an existing email program?

Deep breath: you don’t have to fix every email you’ll ever send, because you don’t design every email from scratch. You design templates, and templates cascade. Fix the template once and every future send inherits the fix. Here’s the retrofit path, in order of payoff:

1. Template level (do once): convert image-text headlines to live text; set real heading elements and a logical source order; mark layout tables presentational and set the language attribute; fix body font size, line spacing, and left alignment; rebuild image-buttons as padded HTML links with strong contrast; solve the dark-mode logo; check every text/background combination with a contrast tool.
2. Content level (every send): alt text for meaningful images, empty alt for decorative ones; standalone link text; no color-alone meaning; plain language and a descriptive subject line; a clean plain-text part.
3. Process level (ongoing): add the quick-test workflow to your pre-send checklist, and schedule your sends far enough ahead that there’s room to fix what testing finds. If your sends currently happen in a last-minute scramble, building out an email content calendar is secretly an accessibility tool — breathing room is what makes testing actually happen.

A worked before-and-after

Before (the inaccessible promo): One large hero image containing the headline “SPRING SALE — 30% OFF EVERYTHING,” the dates, and a picture of a button, with alt=”spring.” Below it, centered pale-gray 12px text, a row of products where the sold-out ones are shown in red with no label, and three links that all say “Click here.” With images off, the email is blank. To a screen reader, it’s “image: spring… click here, click here, click here.” In dark mode, the navy logo on a transparent background vanishes.

After (the accessible rewrite): A live-text headline (real h2): “Spring sale: 30% off everything through Sunday.” The hero becomes a supporting product photo with alt=”Flat-lay of the spring collection: canvas tote, linen shirt, and woven sandals.” Body copy is 16px, dark on light, left-aligned, two short paragraphs. Sold-out items say “Sold out” in text next to the color change. The button is a padded HTML link reading “Shop the spring sale,” with white text on a deep purple that passes contrast in both modes. The logo has a subtle light keyline so it survives dark mode. The plain-text part opens with the headline, the dates, and one clean URL. Same campaign, same design spirit — and now every subscriber receives it.

Your email accessibility checklist

Save this. Run it. The template section is a once-per-template job; the per-send section takes a few minutes once it’s muscle memory.

Template-level (fix once, benefit forever):

• All headlines and body copy are live text — no images of text
• Real heading elements in a logical hierarchy; lists coded as lists
• Source order reads sensibly top to bottom; layout tables marked presentational
• Language attribute set
• Body text roughly 14px or larger, comfortable line spacing, left-aligned
• Buttons are padded HTML links with strong label contrast and generous tap targets
• All text/background pairs pass a contrast check in light and dark mode
• Logo survives dark mode (no vanishing transparent PNG)

Per-send (every email):

• Meaningful images have content- or function-describing alt text; decorative images have empty alt
• Every link makes sense read alone — no “click here”
• No meaning conveyed by color alone — words or icons accompany every color signal
• No flashing content, ever; any GIF is gentle and its first frame carries the message
• Plain language, short paragraphs, descriptive subject line
• Clean plain-text version included
• Quick tests run: images off, zoom, dark mode, screen-reader listen

One last warm thought before the FAQ: the instincts you build here travel. Alt text on email images and alt text on your Instagram posts are the same craft. Captions on video, descriptive link text, contrast-checked graphics — accessible habits make every channel you publish on kinder and more effective, not just your inbox.

FAQ: how to make emails accessible

What is the most important first step to make emails accessible?

Replace images of text with real, live HTML text. The all-image email is unreadable to screen readers, blank when images are turned off, and blurry when zoomed. Once your headlines, body copy, and buttons are genuine text, every other accessibility improvement has a foundation to build on.

How do I write good alt text for email images?

Describe the image’s content or function in one useful sentence — what it shows, or what it does if it’s a link. Purely decorative images should get an empty alt attribute (alt=””) so screen readers skip them cleanly. If you’re writing paragraphs of alt text to carry an image full of words, the real fix is converting those words to live text.

Do animated GIFs break email accessibility?

Not inherently, but they need restraint. Never include flashing or strobing content of any kind — it can trigger seizures in photosensitive readers. Keep animation gentle and slow, and make sure the first frame carries the message, because many clients and settings display only that frame.

Are automated accessibility checkers enough to rely on?

No — they’re a useful first pass, not a verdict. Checkers reliably catch mechanical issues like missing alt attributes or some contrast failures, but they can’t judge whether your alt text is meaningful, your reading order makes sense, or your link text stands alone. Pair a checker with an images-off preview and a brief screen-reader listen using free tools like VoiceOver or NVDA.

Does making emails accessible hurt the design?

It genuinely doesn’t have to. Live text, strong contrast, readable sizes, left-aligned copy, and clear buttons are hallmarks of good email design anyway. Most accessibility work happens at the template level — fixed once, inherited by every future send — and the result usually looks cleaner and converts the skim-readers better too.