KoltrixAn accessibility checklist for plain and HTML email
Make email readable for screen reader users, people with low vision and anyone on a bad connection. A practical checklist for text, structure, color and images.
On this page(11 sections)
Accessible email is not a special edition for a small group. It is email that still works when images are blocked, when the screen is small, when the reader is in bright sunlight, or when a screen reader reads it aloud. Most of the work is plain care with words and structure, and it makes every message better.
This is a checklist you can run before you send a template, a campaign or a product notification. It covers plain text first, because everything else builds on it, and then HTML. It is not a legal standard or a substitute for testing with real assistive technology, but it catches the problems that appear most often.
Start with plain text
A message that reads well in plain text will usually read well everywhere. The reasons are in why the plain-text part matters.
- Include a real plain-text part in every HTML message, written for the same message and not generated from a stripped template.
- Put the point in the first lines. A screen reader user hears the message in order. Lead with what happened and what, if anything, they need to do.
- Use short paragraphs and plain words. One idea per paragraph. Avoid unexplained abbreviations and idioms.
- Write link text that makes sense alone. "Reset your password" is clear. "Click here" and a bare long URL are not, because screen reader users often jump through a list of links.
- Spell out dates and amounts. "Tuesday, 14 October, 3:00 pm UTC" beats "10/14 @ 3". Add the time zone where it matters.
- Do not use characters as decoration. Rows of dashes, arrows, or emoji used as bullets are read aloud one by one.
Structure in HTML
HTML email lets you add meaning that a screen reader can use. Use it plainly.
- Set the language on the root element, such as
lang="en", so the right pronunciation is used. If a section is in another language, mark it. - Give the message a title. The
<title>element is read in some clients and used as a label in others. - Use real headings and lists. A line in large bold type is not a heading to assistive technology. Use heading tags where they exist, and
<ul>or<ol>for lists. Keep the order logical: do not skip from the top heading to a small one for the sake of its size. - Use tables for layout with care. Most email layouts use tables, which is fine, but mark them as presentational with
role="presentation"so a screen reader does not announce rows and columns. Use true data tables only for data, with header cells. - Keep reading order and visual order the same. If a two-column layout stacks on a phone, the content order must still make sense when read top to bottom.
- Put the main action in the body. A button that appears only as an image is invisible to some readers. See below for buttons.
Transactional HTML rendering constraints explains which of these features each client supports, which is worth reading before you rely on any of them.
Color and contrast
Low contrast is the most common accessibility fault in email, and the easiest to prevent.
- Check text contrast. Aim for at least 4.5:1 for normal text and 3:1 for large text. Grey on white and light blue on blue are the usual failures.
- Do not use color alone. A red "failed" and a green "paid" look the same to someone with color blindness. Add words or symbols that carry the meaning.
- Test dark mode. Many clients invert or adjust colors. Check that logos, buttons and links remain visible against a dark background, and that a transparent image does not turn into a black box.
- Make links recognizable. Underline them or give them another clear cue beyond color.
Type and spacing
- Use a readable size. Body text of 16 px is a good default. Anything below 14 px is a strain for many readers.
- Leave room between lines and paragraphs. A line height around 1.4 to 1.5 helps.
- Avoid long lines. Keep the content column to roughly 600 to 700 px so lines stay a comfortable length.
- Allow text to resize. Do not set text in images, and do not lock sizes in ways that stop a user from enlarging the text in their client.
- Left-align body text. Justified text creates uneven gaps, and centered paragraphs are hard to follow.
Images
- Add alt text to every image that carries meaning. Describe what the image does or says, not what it is: "Chart: signups grew from 120 to 310 in March" rather than "chart".
- Mark decorative images as decorative. Use an empty
alt=""so screen readers skip them. - Never put the only copy of important information in an image. Many clients block images by default, and screen readers cannot read text inside a picture.
- Style the alt text. When an image is blocked, the alt text shows in its place. Set a font size and color so it is readable.
- Keep images light. Large files load slowly on weak connections, which is an accessibility issue too.
- Set width and height so layout does not jump as images load.
Buttons and links
- Make buttons real links styled as buttons, with text inside, not an image of a button.
- Give targets room. Aim for at least 44 by 44 px, with space between neighboring links, so people using a thumb or with limited dexterity can hit them.
- Keep the number of links modest. A message with thirty links is tiring to navigate by keyboard or screen reader.
- Say where a link goes when it leaves the expected path, for example "(opens a PDF)".
- Offer a plain way out. If a link is the only way to do something critical, such as resetting a password, also state what to do if the link does not work.
Motion and media
- Avoid animated GIFs that flash. Content that flashes more than three times a second can trigger seizures. Keep any animation slow, short and non-essential.
- Provide a text alternative for video. A still image linked to a video should say what the video is about and how long it is.
- Do not autoplay anything. Clients rarely allow it anyway, and it creates problems where it works.
Attachments and documents
- Say what is attached in the body of the message, with the file name and type.
- Prefer accessible formats. A tagged PDF or a web page works better with a screen reader than a scanned image of a document. For more on handling files, see transactional attachments.
Words matter as much as markup
- Write a clear subject line and preheader. A subject that says what the message is lets people decide how to read it. The preheader should add information, not repeat the subject.
- Name the sender plainly. A real name or company beats a string of symbols.
- Be consistent. Put recurring items, such as the account name or the order number, in the same place in each message.
- Avoid urgency language that adds anxiety. It is harder for many readers to parse and less accessible to those under stress.
How to test
Checklists find the obvious faults. Testing finds the rest.
- Read it as plain text. Does it make sense on its own?
- Turn images off and read it again. Is anything lost?
- Zoom to 200 percent in a browser and in your phone's accessibility settings. Does the layout hold?
- Use a screen reader on a real message: VoiceOver on a Mac or iPhone, TalkBack on Android, NVDA on Windows. Listen for odd order and unlabeled links.
- Run a contrast checker on your text and button colors.
- View it in dark mode on at least two clients.
- Send it to someone who uses assistive technology every day. Ten minutes of their feedback is worth more than any tool.
Keep the results with the template, so the next change starts from a known good state. The same discipline applies to replies written by hand: signatures that work covers the part of every message that is easiest to overload.
Key takeaways
- Write a real plain-text part and lead with what matters.
- Use meaningful headings, lists, link text and language settings in HTML, and mark layout tables as presentational.
- Check contrast and dark mode, never rely on color alone, and give every meaningful image useful alt text.
- Make buttons real links with large targets, avoid flashing animation and say what is attached.
- Test with images off, at 200 percent zoom and with a screen reader before you send to a list.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
