Updated · 8 min read
Email accessibility: the seven rules that make your emails readable by everyone
Picture the user you never see in the analytics dashboard. They're on a four-year-old Android with the brightness pinned because they're standing on a tram platform at noon. They're running a screen reader because their vision's not what it was. Their corporate Outlook strips images by default and asks them to click a link to load each one. They're about a sixth of your list. Most email programs accidentally design around the other 85% — small text, low contrast, image-only CTAs, alt text written like ad copy. The fixes are cheap. The audience gain is real. Here are the seven rules that move an inaccessible program into "usable by everyone" without a rebuild.
By Justin Williames
Founder, Orbit · 10+ years in lifecycle marketing
The user you never see in analytics
Every accessibility fix that helps a screen-reader user also helps a user in direct sunlight, a user on a slow connection whose images didn't load, and a user scanning in three seconds. It's not a niche concern. It's the design choice that survives edge cases.
The standard most teams will eventually be measured against is WCAG — the Web Content Accessibility Guidelines, the rulebook for making digital content usable by people with disabilities. Email is held to the same bar as the web. Most email programs aren't compliant. The good news is that 80% of the improvement comes from seven rules that take a day to implement and become default once you've internalised them.
Compliance is a real concern on top of the user one. WCAG-based lawsuits have been climbing in the US (under the ADA), the EU (under the European Accessibility Act, in force from 2025), and the UK, and email is increasingly in scope. A template audit costs less than a single settlement.
The seven rules
Rule 1: Alt text on every image. Alt text is the text that loads when an image doesn't — and what a screen reader speaks aloud in place of the picture. Decorative images (spacers, ornaments, divider lines) should have alt="" — empty but present, so the screen reader skips them cleanly. Content images describe what they show: "Blue hero image with 'Summer Sale 30% off' headline". Never use alt text as a sales pitch. It's meant to describe, not persuade — misusing it misleads the users who depend on it most.
Rule 2: Real text, not text inside images. Text baked into an image can't be read by screen readers, resized by users, or translated by the browser. If a CTA or headline is text, it should be HTML text. "Bake the headline into the hero so the font renders" was a 2012 pattern; web fonts work well enough in 2026 to retire it. @font-face — the CSS rule that loads a custom font from your server — is supported across Apple Mail, Outlook for Mac, and most Gmail configurations. Always specify a fallback (font-family: 'YourBrand', Arial, sans-serif) so the email stays readable when the web font doesn't render.
Rule 3: 4.5:1 contrast ratio for body text. Contrast ratio is the brightness gap between text colour and background, measured on a scale where 1:1 is invisible and 21:1 is pure black on white. WCAG AA — the middle-tier compliance level most regulators reference — requires 4.5:1 for body text. Use a contrast checker (WebAIM's free one runs in 10 seconds) on every colour pair in the template. A common failure: light grey disclaimer text on white, scoring 2.1:1. Looks clean on your designer's retina display. Unreadable for a big slice of your audience.
Rule 4: 3:1 contrast for UI elements. Buttons, borders, icons need at least 3:1 against their background. A light-blue CTA on a white background often fails this; brand palettes frequently need a darker variant specifically for accessible buttons. Worth building into the brand guidelines so it doesn't get re-litigated every template.
Rule 5: Semantic HTML where possible. Semantic HTML means using elements that describe what content is, not just how it looks — <h1> for the top heading, <p> for paragraphs, <a> for links. Screen readers move through email by element type — a "heading" that's really a styled <div> doesn't register as a heading and disappears from the user's mental map of the email. Tables for layout are still acceptable in email because Outlook quirks force the issue, but mark layout tables with role="presentation" so screen readers don't announce them as data tables. Beyond that, ARIA — the set of attributes that adds accessibility hints to HTML — has limited support across email clients; semantic HTML does more heavy lifting than ARIA ever will in this channel.
Rule 6: Descriptive link text. "Click here" and "Learn more" are the classic accessibility failures. Many screen reader users pull up a list of every link in the email to scan it on its own — "Click here" tells them nothing. Use action text: "View your order", "Read the full article", "Update your preferences". This is usually the single biggest accessibility lift in an audit because it's everywhere and it's easy to fix.
Rule 7: Language attribute on the root HTML. <html lang="en">, or the correct language code. Screen readers change voice and accent based on this; without it, a French-language email read by an English screen reader sounds like garbled nonsense. One line of code. Nobody remembers to add it.
The ten-minute audit you can run right now
The fastest way to find out which of the seven rules your template breaks is to actually run through it on a live email. Open one in your browser preview, set a timer, and walk through these checks in order.
What most programs get wrong
Over-reliance on images. Templates that are essentially a single hero image with text baked in. Looks great in Figma. Inaccessible. Also a problem when Outlook blocks images by default, which is often. Text-based content with images as supporting visuals renders more reliably and reads for more users.
Low-contrast "design". A trendy palette of light grey on white reads as sophisticated to the designer and unreadable to everyone in bright light, with low vision, or on a cheap display. Contrast is the floor that determines whether anyone sees your design at all — not a constraint to fight.
Tiny fonts. 12px body text for "design density". See the mobile design guide — iOS auto-bumps anything under 16px to 16px anyway, so you're fighting the operating system for no gain. Anything below 14px is actively inaccessible.
Generic link text. "Click here" as the entire anchor on every CTA. Trivial to fix, and often the single highest-impact lift the template will ever get.
Dark mode sits adjacent to this and confuses people. Dark mode support is about user preference; accessibility is about users who can't use a standard render at all. The two overlap — broken dark-mode renders often collapse contrast below thresholds, which lands you with an accessibility failure on top of a design one. The dark mode design guide covers the render-mode-specific rules.
Why this earns its way onto the roadmap
Three measurable business impacts beyond the obvious "more users can read the email".
Legal exposure goes down. Covered above. Rising lawsuit volume, email in scope, template audit vastly cheaper than a single settlement. Boring math, but the math works.
SEO-adjacent signals. For emails that link to web content or transactional emails with web versions, accessibility practices align with web accessibility — which is a Google ranking signal. Small effect, but free.
Image-blocked rendering improves. Plenty of users see emails with images blocked — Outlook default, slow connections, corporate gateways. Alt text and text-based content mean those opens still produce readable content instead of empty rectangles with a "click to download images" prompt.
builds accessibility into default template QA. Templates that don't pass the seven-rule check don't ship. Once that's the policy, the whole problem quietly stops being a problem.
Read to the end
Scroll to the bottom of the guide — we'll tick it on your reading path automatically.
Frequently asked questions
- What makes an email accessible?
- Six practices. Semantic HTML — real <h1>-<h6> hierarchy, not styled <div>s. Alt text on every image that carries meaning. Sufficient colour contrast — 4.5:1 minimum for body text, 3:1 for large text. Minimum 14-16px font size for body copy. Descriptive link text — "Read the guide" beats "Click here." Plain-text alternative in the MIME structure for screen-reader and low-bandwidth fallback. Combined, these make emails usable by screen readers, low-vision users, and anyone with a small viewport or bad connection.
- Do email clients render HTML like browsers?
- Nowhere close. Email HTML is roughly 1998-era HTML — table-based layouts, inline styles, no JavaScript, limited CSS support (no flexbox reliably, no grid, no CSS variables). Each client has its own quirks: Outlook (desktop) uses Word's rendering engine and ignores many CSS properties; Gmail strips <style> blocks in some cases; Apple Mail is the closest to modern web standards. Accessibility in this context means designing for the ancient-HTML baseline, not modern web patterns.
- How should alt text be written for marketing emails?
- Descriptively, not decoratively. Good: "Product hero: new fall collection jacket in navy." Bad: "Image1.jpg" or "(decorative)". For purely decorative images (spacers, background textures), use alt="" explicitly — empty alt tells screen readers to skip. For images carrying the primary CTA, duplicate the CTA text in alt — if the image doesn't load, the reader still sees the call-to-action.
- What's the minimum font size for email body text?
- 14px is the operator standard minimum. 16px is safer, particularly on mobile where 14px can feel cramped. Avoid fonts below 12px — they cross the accessibility threshold for many users with age-related vision changes. Big tech email (Amazon, Netflix) typically uses 16px+ body text for this reason. Headlines can be larger; fine-print (legal, unsubscribe language) can go to 11-12px if legally required but not smaller.
- Does email accessibility help deliverability?
- Indirectly, yes. Accessibility improves engagement (more people can read and interact with the email), which feeds back into sender reputation. More directly, well-structured semantic HTML with a plain-text alternative is a small positive signal to mailbox providers — it pattern-matches to legitimate senders and against spam, which typically has messy HTML and missing plain-text. The effect is modest but real over time.
This guide is backed by an Orbit skill
Related guides
Browse allEmail dark mode: the four render modes and how to not break any of them
Dark mode in email is four different render behaviours across major clients, each with its own logic. Design without knowing which mode you're hitting and roughly half your audience sees something you never approved. Here's what each client does and the defensive rules that survive all of them.
Mobile email design: 65% of opens are on a phone — design for that
Two-thirds of email is opened on mobile. Most designs still start with desktop and hope it collapses. Here are the mobile-first rules that reliably produce emails that read, click, and convert on a phone.
Transactional emails: the highest-engagement messages you ignore
Order confirmations, password resets, receipts, shipping updates. Transactional emails post open rates two to three times higher than marketing sends — and most lifecycle teams have never touched them. Effort is going to the wrong place.
Personalisation that doesn't feel creepy
There's a line between personalisation that earns trust and personalisation that breaks it. It's not where most people think it is — it's about how you signal what you know, not what you know. Here's the line, how programs cross it without noticing, and the patterns that keep you on the right side.
Subject line anatomy: the four parts every line that performs shares
Most subject-line advice is decoration tips — emoji, length, numbers. The lines that actually get opened share a structural pattern. Four parts in a specific order, the three distortions that ruin it, and the four rules that keep A/B tests honest.
Preheader text: the second subject line most programs ignore
The preheader is the snippet shown next to the subject line in the inbox preview. Treat it like a second subject line and you double your hook. Treat it like an afterthought and it says 'View this email in your browser'. Here's how to write preheaders that actually earn the open.
Found this useful? Share it with your team.
Use this in Claude
Run this methodology inside your Claude sessions.
Orbit turns every guide on this site into an executable Claude skill — 63 lifecycle methodologies, 91 MCP tools, native Braze integration. Free for everyone.