Email Accessibility: How to Make Your Campaigns Readable for Everyone

15% of the world's population lives with some form of disability. Among them are your subscribers, customers, and partners. If your email can't be read with a screen reader or parsed with low vision, you lose those people. Silently.

Email accessibility is not charity work. It's a discipline that improves messages for everyone: people reading in dark mode, on slow connections, on small screens, or with images disabled.

Why accessibility matters in email

Websites have lived under WCAG standards for years. Email has lagged behind, but the gap is closing. The EU's European Accessibility Act now covers digital communications. In the US, ADA and Section 508 apply. Neither is optional if you send at scale.

Legal context aside, there are three concrete reasons to care:

• Reach. According to the WHO, 2.2 billion people have some form of vision impairment. Some use screen readers; others just bump up their font size.
• Quality. An accessible email is better structured, loads faster, and renders correctly in non-standard mail clients.
• Deliverability. Proper alt text, a healthy text-to-image ratio, and clean markup are exactly what spam filters reward.

Alt text for images

The most common mistake in email campaigns: images with no alt text. A screen reader hits that image and reads aloud "Image". Or, worse, the filename: "banner_final_v3_updated.png". For someone who can't see the screen, that's noise.

If the image carries meaning, describe it. A banner saying "30% off through Friday" needs an alt like "30% off all plans through Friday". If the image is purely decorative, leave the alt empty: alt="". An empty alt tells the screen reader: "Skip this, nothing important here".

Emails built as a single image are completely invisible to screen readers without alt text, and spam filters hate them too. If your designer sends a mockup as an image file, convert the text to HTML. Not a compromise; a requirement.

Semantic structure: headings, lists, tables

Screen readers let users jump between headings, lists, and links. That only works when the markup is semantic. If everything sits in <div> and <span>, navigation is impossible.

Email has constraints: not every mail client supports <article> or <nav>. But the basics work everywhere:

• <h1> – <h3> for headings (hierarchy matters — don't skip levels)
• <p> for paragraphs, not <div> with spacing hacks
• <ul> and <ol> for lists
• <table role="presentation"> for layout tables (so the screen reader doesn't announce cell coordinates)

Add lang="en" to the root HTML tag of your email. Without it, a screen reader may read English text with the wrong language profile, mangling pronunciation. This happens more than people expect.

Contrast: making text actually readable

WCAG requires a contrast ratio of at least 4.5:1 for body text and 3:1 for large text (18px or larger, or 14px bold). Light gray on white is a classic email design move and a classic accessibility failure.

Checking contrast takes seconds: WebAIM Contrast Checker, Figma plugins, or Chrome DevTools. Making it a habit before every send pays off immediately.

Dark mode is a separate problem. Apple Mail, Gmail, and Outlook all invert or override colors automatically. Dark text on a transparent background can become dark text on a dark background. The fix: set background colors explicitly and test in both modes.

Font size and button targets

Body text needs to be at least 16px. Not 12, not 14. At 14px, someone with normal vision already strains on a phone screen. With any vision impairment, the text becomes unreadable.

Buttons and links need a tap target of at least 44x44 pixels. That is Apple's Touch Target recommendation, and it applies directly to email. A "Learn more" link at 10px text is hard to tap even without a motor impairment.

Line height should be 1.5 times the font size or more. Dense text is hard on readers with dyslexia and cognitive disabilities. Dense text is also just hard to read.

Link text: not "click here"

Screen readers can pull up a list of all links on a page. If every link says "click here" or "read more", that list is useless. The user has no idea where each link leads.

Links also need to be visually distinct from body text by more than color alone. Add an underline. About 8% of men have some form of color blindness, where a blue link on black text can be indistinguishable without an underline.

Tables: layout vs. data

Email is still built on tables. The problem: screen readers try to announce each cell as part of a data table. Column 1, row 3, content... On an email with 15 layout tables, this becomes genuinely painful to listen to.

The fix: role="presentation" on every layout table. This tells the screen reader: "Not a data table, just pass through". For actual data tables (an order receipt, for example), use <th> for column headers and the scope attribute.

Interactive elements and animation

AMP emails, CSS animations, carousels — all gaining popularity. But if an interactive element is the only way to access information, subscribers with JavaScript disabled or an AMP-incompatible client will see nothing.

Every piece of content must be available in a static HTML fallback. Have a product image carousel? Fine, but list all the images below it as regular <img> elements with alt text. Running a countdown timer? Duplicate the date as plain text.

Flashing content that fires more than 3 times per second is contraindicated for people with photosensitive epilepsy. GIF banners with fast frame rates are in that zone.

Checklist: 10 points before you send

None of these require rebuilding your template from scratch. Most are a few lines of code. Together they take an email that was inaccessible to a chunk of your audience and make it readable for all of them.

Testing email accessibility

Manual test: open your email, close your eyes, turn on VoiceOver (Mac) or NVDA (Windows). Listen to how the screen reader reads your email. That experience sticks better than any checklist.

Automated tools: Litmus and Email on Acid both include accessibility checks as part of their testing suite. Microsoft's Accessibility Insights works for web versions of emails. axe DevTools is good for a quick contrast and markup check.

Don't forget the plain-text version. Some subscribers read email in that format by choice or because their screen reader is configured that way. A plain-text version needs to carry all the content, all the links, and a structure that makes sense without any HTML.

Accessibility is part of quality

It belongs alongside validating email addresses, checking rendering across clients, and A/B testing subject lines. Build it into your process and it stops being extra work.

Start with alt text and contrast ratios. Those two changes cover the majority of accessibility failures. Then add semantic markup and run a screen reader test. Within a week your emails get better for millions of people you were previously just ignoring.