Updated · 8 min read
Email accessibility: the seven rules that make your emails readable by everyone
15% of your audience has some form of vision, motor, or cognitive difference that affects how they read email. Most email programs accidentally design around the other 85% — small text, low contrast, image-only CTAs, missing alt text. The fixes are cheap and the audience gain is real. Here's the seven-rule shortlist that moves an inaccessible email program into 'usable by everyone' without a rebuild.
Justin Williames
Founder, Orbit · 10+ years in lifecycle marketing
Why it matters beyond compliance
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 3 seconds. It's not a niche concern — it's the design choice that survives edge cases.
WCAG (Web Content Accessibility Guidelines) are the standard; email is held to the same bar as web. Most programs are not compliant. The good news: 80% of accessibility improvement comes from seven rules that take a day to implement and become default once learned.
The seven rules
Rule 1: Alt text on every image. Screen readers rely on alt text. Decorative images (spacers, ornaments) should have alt="" (empty but present). Content images should describe what they show: "Blue hero image with 'Summer Sale 30% off' headline". Don't use alt text as a sales pitch — describe the image accurately.
Rule 2: Real text, not image text. Text inside an image can't be read by screen readers, resized by users, or translated. If a CTA or headline is text, it should be HTML text, not an image. "Designed as an image for font control" is a 2012 pattern; web fonts in email work well enough in 2026.
Rule 3: 4.5:1 contrast ratio for body text. WCAG AA standard. Use a contrast checker (WebAIM has a free one) on every colour pair. A common failure: light grey text on white background for "disclaimer" text — looks clean, scores 2.1:1, unreadable for many users.
Rule 4: 3:1 contrast for UI elements. Buttons, borders, icons need 3:1 against their background. A light-blue CTA on a white background frequently fails this; brand colour palettes often need a darker variant for accessible buttons.
Rule 5: Semantic HTML where possible. Use <h1>, <h2>, <p>, <ul>, <a>. Screen readers use the element structure to navigate. A "heading" that's really a styled <div> doesn't register as a heading in the screen reader's navigation. Tables for layout are still acceptable in email (Outlook quirks), but use role="presentation" on layout tables.
Rule 6: Descriptive link text. "Click here" and "Learn more" are classic accessibility failures. Screen reader users often navigate by pulling a list of all links on the page; "Click here" tells them nothing. Use action-oriented link text: "View your order", "Read the full article", "Update your preferences".
Rule 7: Language attribute on the root HTML. <html lang="en"> (or appropriate language code). Screen readers change voice/accent based on this; without it, a French-language email read by an English screen reader sounds like garbled nonsense.
The quick accessibility audit
,
What most programs get wrong
Over-reliance on images. Email templates that are essentially a single hero image with text baked in. Looks great; inaccessible; also problematic if images are blocked by default (Outlook). Shift to text-based content with images as supporting visuals.
Low-contrast "design". A trendy palette of light grey text on white background looks sophisticated; it's unreadable for users with low vision, in bright light, or on low-quality displays. Contrast isn't a design constraint to fight — it's the foundation that determines whether anyone sees your design at all.
Tiny fonts. 12px body text for "design density". See the mobile design guide — iOS auto-bumps text under 16px to 16px anyway. Below 14px is actively inaccessible.
Generic link text. "Click here" as the only anchor text on every CTA. Easy to fix; often the single biggest accessibility lift in an audit.
The business case
Accessibility has three measurable business impacts beyond the obvious "more users can read your email":
1. Legal exposure. WCAG-based accessibility lawsuits have been rising in the US (ADA), EU (EAA, applicable from 2025), and UK. Email is increasingly within scope. A template audit costs less than a single settlement.
2. SEO-adjacent signals. For emails that link to web content or for transactional emails with web versions, accessibility practices align with web accessibility, which is a Google ranking signal.
3. Image-blocked rendering. Even users without disabilities often see emails with images blocked (Outlook default, slow connections). Alt text and text-based content ensure these opens still produce readable content, not empty rectangles.
includes accessibility as a default QA step. Templates that don't pass the seven-rule check don't ship.
Frequently asked questions
- How do I write good alt text?
- Describe what the image shows, briefly and accurately. For content images: 'Blue hero image with "Summer Sale 30% off" headline'. For logos: '[Brand] logo'. For decorative images: empty alt='' so screen readers skip it. Never use alt text for marketing copy — it misleads users and fails the intent.
- Do I really need to worry about contrast ratios?
- Yes. 4.5:1 for body text is the WCAG AA baseline. Users with low vision, users in bright light, users on older displays all rely on adequate contrast. WebAIM's free contrast checker lets you verify any colour pair in 10 seconds. Most accessibility audit failures start here.
- Can I use web fonts in email?
- Yes, with fallbacks. Major clients (Apple Mail, Outlook for Mac, some Gmail configurations) support @font-face. Always specify a fallback: font-family: 'YourBrand', Arial, sans-serif. Don't rely on web fonts rendering universally; the email must still be readable in the fallback.
- Should I use ARIA attributes in email?
- Use role='presentation' on layout tables (so screen readers don't announce them as tables). Beyond that, ARIA has limited support across email clients. Semantic HTML (real headings, real lists, real links) does more for accessibility than ARIA in email.
- What about keyboard accessibility in email?
- Less relevant for email than web, because most email is consumed via touch (mobile) or scroll (desktop). But for users who navigate via keyboard, ensure link order follows visual order and that focus indicators (when the email is viewed in a browser) are not suppressed via CSS like outline: none.
- Is dark mode an accessibility issue?
- Related but separate. Dark mode support is about user preference; accessibility is about users who can't use a standard render. The two overlap: broken dark-mode renders often reduce contrast to unreadable levels, which is an accessibility failure. See the dark mode design guide for the render-mode-specific rules.
Related guides
Browse all →Preheader text: the second subject line most programs ignore
Preheader text is the snippet shown next to the subject line in the inbox preview. Done well, it doubles your hook. Done badly, it says 'View this email in your browser'. Here's how to write preheaders that earn the open.
Email dark mode: the four render modes and how to not break any of them
Dark mode in email isn't one thing — it's four different render behaviours depending on the client. Design without knowing which mode you're hitting and your emails will look broken to 40% of your audience. Here's what each client does.
Mobile email design: 65% of opens are on a phone — design for that
Two-thirds of email is opened on mobile. Most email designs still start with a desktop layout and hope it collapses well. Here's the mobile-first rules that reliably produce emails that read, click, and convert on a phone.
Transactional email anatomy: the five sections every transactional needs
Transactional emails get opened at 3–5× the rate of marketing and carry more brand signal per send. Most programs treat them as ops artefacts and miss the leverage. Here's the five-section template that works for every transactional type.
Brand voice in lifecycle: how to sound like you — not the generic SaaS CRM voice
Lifecycle emails drift toward a generic 'polished SaaS CRM voice' because it's the default pattern in every template library and every agency deliverable. Here's how to actually write in your brand's voice across an entire lifecycle program.
The email copywriting pyramid: write for the 5-second reader first
Most email recipients read for 5 seconds before deciding to engage or delete. The email has to work at that reading depth and still reward a longer read. The inverted pyramid structure — lead with conclusion — is how to do it.
Found this useful? Share it with your team.