Why email needs care
Email is read in many different ways: on a phone, in a desktop client, through a screen reader, with images turned off, in dark mode, or with text enlarged. Email clients also render code inconsistently, so a design that looks perfect in your testing tool can behave differently elsewhere. That is exactly why accessible habits help: they make the email robust, not just compliant.
The advice below is general. Your email tool may have its own accessibility options, so check its current documentation.
Use a clear structure
People who use screen readers often move through an email by headings and links. People who skim do the same by eye.
- Use one main heading and sensible subheadings. Where your tool allows real heading elements, use them rather than just making text large and bold.
- Keep a logical reading order. Content should read top to bottom in a sensible sequence. Multi-column layouts can be read in an odd order by assistive technology, so keep layouts simple, particularly on mobile.
- Avoid layout tables used purely for decoration where you can. Many email builders use tables to position content. Setting the table’s role as presentation, where your tool allows, tells assistive technology it is layout, not data. Only use real tables for real tabular data.
- Write a short, informative subject line and preheader. These are the first thing anyone reads. Subject line testing can compare options, but clarity should come before cleverness.
- Set the language of the email where your tool offers the option, so screen readers choose the right pronunciation.
Text size and readability
- Use body text of around 16 pixels or larger. Small text is hard on a phone and for people with low vision.
- Use real text, not text baked into an image. Images of text cannot be resized, selected or read aloud by a screen reader, and they vanish when images are blocked.
- Keep lines reasonably short and leave white space between sections.
- Left-align body copy.
- Check colour contrast between text and background. Body text typically needs a ratio of at least 4.5:1 under the commonly used WCAG AA level, and button text is no exception. Also check how the email looks in dark mode.
- Avoid whole sentences in capitals, and avoid fancy Unicode “fonts”.
Write descriptive link text
Screen reader users can pull up a list of all links in an email. A list that reads “click here, click here, read more, read more” is useless. Make each link make sense on its own: “View the autumn price list” instead of “Click here”. This is covered in detail in our article on link text, and it helps everyone who scans.
Other link and button tips:
- Make buttons large enough to tap easily, with space around them so people don’t hit the wrong one.
- Avoid placing many links tightly together.
- Do not rely on colour alone to show something is a link; underline links in body text.
- Use real text for buttons rather than a button image. If you do use an image button, give it a clear text alternative.
- Keep a single, clear call to action where possible, and word it plainly.
Handle images properly
Many people see emails with images blocked by default, and screen reader users hear alternatives instead of pictures.
- Add a short alt text to every meaningful image, describing what matters. Decorative images should have empty alt text so they are skipped.
- Do not put essential information, such as a date, price or offer code, only inside an image.
- Check how the email looks with images off. Alt text may be displayed in its place, so style it to be legible.
- Avoid images made only of text, such as full-width banners with the whole message baked in.
- If you use animated GIFs, avoid rapid flashing, keep them short, and make sure the key message is also in text.
Include a plain text version
Most email tools can send a multipart message: an HTML version and a plain text version. The plain text part is shown if the recipient’s client cannot or does not display HTML, and some people choose it deliberately. It can be easier for some assistive technology and for people on very slow connections.
A good plain text version:
- Contains the same content and offers, not a stub saying “view this email in your browser”.
- Keeps a clear order, with simple headings written as text.
- Shows links as readable text, with the full address visible where it helps.
Check whether your email tool generates it automatically, and read what it produces. Auto-generated versions are sometimes messy.
Offer a web version and an easy way out
A “view in browser” link helps when an email renders badly. Make sure it works. Equally, a visible, easy-to-use unsubscribe link is part of treating readers well, and in many places it is a legal requirement. Rules on consent and unsubscribing vary by country and change over time, so check the ones that apply to you; this is not legal advice. Our article on how to make it easy to unsubscribe covers that side of things.
Test before you send
- Send a test to a few real clients, including a phone.
- Switch images off and see what remains.
- Zoom the text to a larger size.
- Try dark mode.
- Use a screen reader if you can, or at least tab through the links with the keyboard.
- Read the plain text part.
- Ask someone else to look; fresh eyes spot problems you have stopped seeing.
It also helps to record these steps in your pre-send checklist. A repeatable routine matters more than occasional heroic effort.
Measuring the effect
You may want to know whether these changes pay off. Email metrics such as clicks and replies can move for many reasons, so be wary of crediting one change. Accessibility is worth doing because it makes the email usable, not because it guarantees a lift.