How do accessibility standards (WCAG) apply to email?

You've probably heard that emails should be "accessible," but what does that actually mean in practice? And here's the wrinkle nobody mentions upfront: WCAG (Web Content Accessibility Guidelines) was written for the web. Email clients don't render HTML like browsers do. That means applying WCAG to email takes judgment, not just a checklist.

Still, most of the core principles translate well. Here's what actually matters and how to act on it.

Alt text on images

Screen readers announce images based on their alt attribute. If an image carries meaning, write a short description of that meaning. If it's purely decorative, use an empty alt attribute (alt="") so screen readers skip it. Don't use the image filename as alt text, and don't write "image of" as a prefix. Just describe what matters.

Color contrast

WCAG's AA standard asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. In email, this matters even more than on the web because many clients override CSS, dark mode switches colors on you, and a lot of email gets read on phones in bright sunlight. You can check contrast ratios with any color contrast analyzer before your email goes out. Our free Accessibility Checker catches this automatically.

Link text

"Click here" tells a screen reader user nothing. Screen readers can pull all links out of a page (or email) and list them in isolation. If every link says "click here," that list is useless. Write links that describe the destination or action, "View your invoice," "Read the full guide," "Update your preferences."

Semantic HTML structure

Use heading tags (h1, h2, etc.) in a logical order. Don't use heading tags just to make text bigger. Use them to signal structure. Many email clients support heading semantics, and screen readers use them to help users navigate long content. (That said, Outlook on Windows is notorious for stripping or mangling heading styles, so always test.)

Reading order

Screen readers and some assistive tools follow the source order of your HTML, not how it looks visually. If your email is built with a complex table layout where columns appear in the wrong source order, the reading experience breaks. Single-column layouts or well-structured multi-column code both work, as long as the source order matches the intended reading order.

Font size and spacing

This overlaps with mobile font standards, but it's also an accessibility issue. Keep body text at 14px minimum, 16px preferred. Don't rely on tiny text or tight line spacing. Cognitive load matters too, shorter paragraphs and clear hierarchy help readers with attention or processing differences.

Never convey meaning through color alone

If you mark required fields in red or use green to signal success, add a label, icon, or text to carry that same meaning. About 8% of men have some form of color vision deficiency. Red and green are the most commonly affected colors. Don't make your message invisible to them.

The email client problem

Here's the honest caveat. Email client support for accessibility features varies wildly. Apple Mail has strong support for semantic HTML and ARIA roles. Outlook on Windows renders through Word's engine and ignores a lot. Gmail strips certain tags. That means you can't rely on every technique working everywhere. The strategy is to implement what works broadly (alt text, contrast, link text, font size) and use progressive enhancement for the rest.

The upside is that most accessibility wins are also deliverability and usability wins. Good alt text helps when images are blocked. Descriptive links are easier to click on mobile. High-contrast text reads better for everyone. You're not writing accessible email for a niche audience. You're writing email that works better full stop.

Want to run your email through an accessibility check before you send? Our free Accessibility Checker flags contrast issues, missing alt text, and more in seconds.