Important note: this is a very rough draft/info dump based on an A11Y (Accessibility) Slack Community discussion. It should not be taken as polished or complete advice. You can check out the original thread (opens in a new tab/Slack) if you’re a member of the workspace.
Original Context
A member of the workspace indicated that they’d been searching, mostly in vain, for examples of transactional/marketing emails with accessible HTML, and were looking for guidance on the topic.
My Rough Thoughts
Note that none of this usually relates to conversational emails, e.g. between friends or from clients at work.
Speaking as just one screen reader user, the accessibility of marketing emails is quite universally poor. This applies to some cases more than others, e.g. most marketing emails I’ve received from Audible US or my primary bank consist only of an image. Those are completely exclusionary, and a pain to extract info from.
For the rest, my main questions are usually: can I get the information out of this that I need to, and/or go to an additional resource on the web that is likely to be more pleasant? I’m not spending a huge amount of time with company’s transactional and/or marketing material in my inbox, so my personal bar is admittedly quite low here.
My Quick (Non-Exhaustive) Tips for Email Accessibility
- Keep it simple. The level of support for e.g. ARIA attributes and certain CSS techniques varies widely across email user agents, and a lot will be stripped for security reasons. If you find yourself reaching for things like ARIA, visually-hidden text, and complex interactive widgets, you’re probably on the wrong path.
- Include a readable and complete plain-text equivalent (i.e. via multipart messages so clients can fall back to the text version).
- Never use images of text, or an image of the entire email.
- Carefully determine how much information the email should contain. Is it more appropriate for the email to be a heads-up about a linked resource, rather than a wall of text? Or, is it important that a user is able to download this important info in an email to have available offline?
- Include a link to view the email online in a standard browser.
- Follow other applicable web accessibility techniques, e.g. alt text on images, informative link text, headings used for hierarchy rather than visual appearance, good colour contrast, inclusive language, etc.
- As much as possible, avoid layout tables. There are still screen reader/email client combos, like NVDA and Outlook, where the boundaries of layout tables will constantly be spoken.
- Test! How does it read with NVDA and Outlook, JAWS and Thunderbird, etc.? How does it look on a phone, or when zoomed in? If a user has their email software configured to view plain text or a more basic view, or is using a low data mode, does all of the info come across?
How I Read Emails
I primarily use NVDA with Thunderbird. I press Enter on an email in the list of messages, which opens a webpage-like browsable document, and then read it with the arrow keys (mostly Down Arrow).
If reading email on my phone, I use the iOS Mail app with VoiceOver. I turn off superfluous noise like thread summaries and “AI” categorisation, and just swipe through the list of messages. Double-tap with one finger to open one, swipe left and right to read it paragraph by paragraph.
In other words, I don’t think I do anything special. An email is usually analogous to a webpage that I’m not yet familiar with, so I can’t reach for specific navigational steps.
If I do receive a lot of emails from the same place that all use a similar template, and I know that there are consistent headings or whatever, I can use the appropriate navigation commands. But that’s mostly not the case.
If testing email accessibility as a non-screen reader user, make sure you don’t know the content of the emails upfront (i.e. because you picked them out as examples, and/or you can see them on the screen). That is fundamentally never true for a blind screen reader user like myself.
For instance: before I open the message and start reading, I don’t know if there’ll be a “view online” link, nor if I’ll want/need to use it in this case. While such links might be fairly common, I don’t view it as logical or efficient to go searching for a particular link as the first thing I do after opening every email.
Instead, just reading the email is far quicker. For context, I have my screen reader set to output speech at over 700 words per minute; someone using braille and/or a slower speech rate may feel differently.
While all of this is quite personal, it’s understandably quite common in my experience for non-screen reader users to underestimate the relevance of reading speed in such decisions. To reiterate, it is literally more efficient for me to read the email, work out that something about it is inaccessible, and go looking for a way to “fix” that, than to assume it won’t be accessible and look for specific affordances from the beginning.
One final thing: In all screen readers I know of, there’s a gesture to have a document read from top to bottom (or from the user’s current position to the end), commonly referred to as a “say all”. I personally don’t use this much for emails, where the Down Arrow key and a long line length in the NVDA browse mode settings allow me to scan quite easily. But it’s useful in long articles, ebooks, and the like, and I’m sure many people do use it for email too.
On Useless Information at the Top of Emails
A follow-up question on the thread asked how common it is for me to encounter “useless information” prior to the main content of interest.
My response is that I can’t put a number on that, because I truly don’t pay enough attention. This type of content is simply not important enough for me to care, and as such it takes a lot for an email to be so packed with useless rubbish upfront that I notice.
Again this comes back to the reading speed, and getting a feel for how to skim read using speech. If I was reading purely from top to bottom without interruption, and using a slow speech rate, the amount of bloat at the beginning of emails would be something I would find a lot harder to avoid.
That said, this isn’t an excuse to fill email bodies with junk. I do tend to notice more, in a positive way, when an email cuts to the chase by frontloading the important message.
In Closing
Reminder: these were some rough thoughts I knocked out on a Thursday afternoon in response to some specific questions. I hope they’re helpful to somebody, but they should in no way be interpreted as a primer on email accessibility.
In particular, I mainly focused on email accessibility for me, personally, as a blind screen reader user. There are lots of other important facets of email accessibility for other users who are not me, people who don’t use screen readers and/or have other accessibility needs, etc.