How to Make Email for Everyone in 3 Easy Steps: Webinar Recording + Q&A

Email accessibility has been voted one of the hottest email design trends of 2019, and is now a priority for the majority of brands. But it’s also true that many marketers don’t know how to get started with making their emails more inclusive.

Implementing accessibility best practices is easier than you think. In this webinar, Litmus’ accessibility experts, Jason Rodriguez and Alice Li, walk through the stats and research that prove investing in accessibility is worth it and share the 3 steps you’ll have to take to create better email for everyone.

Didn’t have a chance to watch the webinar live? Don’t worry. You can access the full recording at any time and read the Q&A below.

Q&A

A big thank you to everyone who chimed in during the webinar with a question! Here’s a recap of our answers to the most popular questions, along with our take on some of the questions we didn’t get to during the live webinar. Have any additional questions? Please leave them in the comments.

How do you account for cognitive limitations?

Bettina: There are a lot of different types of cognitive disabilities, from having difficulties memorizing things or paying attention to dyslexia or autism. Each of these conditions is unique, but following the tips in the copywriting and design section of this webinar will go a long way in making your emails more accessible to people with cognitive limitations. For example, keep your email copy clear and concise and avoid the use of difficult words or jargon. Keep your layouts simple and develop a clear visual hierarchy that makes it easy for your subscribers to scan your email—and to quickly understand what’s important (and what’s not).

What is the most used screen reader? How do you test for it?

Alice: The two most popular screen readers are NVDA and JAWS. NVDA is a free, open-source tool developed by NV Access—they are an amazing organization that dedicates their work to making technology more accessible for people with visual impairments. JAWS is a popular subscription-based screen reading tool.

If you don’t want to install software to understand how your email would sound on a screen reader, you can use Litmus for it! We recently integrated NVDA into Litmus, so you can now listen to an audio preview of your email right within Litmus Checklist. Learn more.

Plus, all modern operating systems offer some type of native screen reading support, too. On Mac, for example, it’s that’s VoiceOver.

What are some brands that do a great job optimizing their emails for accessibility? I’d love some inspiration!

Jason: One of my favorites is deque. They do a lot of accessibility training, have an amazing blog—and great emails! Their emails don’t only follow accessibility best practices, but also feature great content that helps you learn about the topic. You should sign up for their newsletter!

At the risk of sounding conceited, I’ve been very impressed with the work Alice and the email team have done on the Litmus newsletter. Not only is it beautifully designed, but they’ve put a lot of work into making it accessible based on the best practices discussed in The Ultimate Guide to Email Accessibility.

Any insight into how tools like “Alexa” or “Siri” differ from other screen readers? Or Outlook’s “read out aloud” feature?

Jason: In a recent episode of the Delivering podcast I took a deep-dive into voice assistants. I found that Alexa is the only one that truly reads your email—but it will only read the HTML text, ignoring any alt attributes, tables or any other HTML elements. It’s different from how a screen reader would handle email. Voice assistants are geared towards convenience, not necessarily towards accessibility, so they don’t work the same way as a full-blown screen reader like NVDA does, for example. In many cases, you still need your phone or your laptop to navigate the content, the voice assistant is only supporting you. For a full run-down on how Alexa, Google Home, Siri, and Cortana handle email, tune in to this podcast episode.

How about animated GIFs? Use them or not? Do they cause issues for readers?

Alice: You can use them, but be careful about how. Animations can trigger photosensitive epileptic seizures so you’ll never want to include a GIF that too jarring or flashing. You also don’t want to include crucial information like copy in your GIFs either. Copy hidden in your GIF is not accessible for screen readers—and it will not display in email clients where images are disabled—so you risk losing crucial parts of your messaging.

Where can I find examples of accessible email templates?

Jason: There are so many free templates out there but not many of them are optimized with accessibility in mind! That’s why we recently created four brand new templates that follow accessibility best practices—and they’re available to you for free in the Litmus Community. Check out our templates if you want to build…

How does the use of emojis impact accessibility?

Jason: While most screenreaders understand emojis and can read them out, it might not be the optimal experience for users. Let’s take a listen to NVDA reading out this example subject line with an emoji:

The biggest sale of the year

You can hear how disjointed an emoji sounds next to text. While emojis are commonplace now and assistive technology users are likely used to hearing them, depending on the emoji it can still sound awkward. Like any other element or copy in an email, the best way to see whether or not it works is to test it out and listen to your email using a tool like NVDA or the Litmus Accessibility Checker.

Do I need to apply “role=presentation” to DIVs, too?

Alice: Nope! role=”presentation” is only intended to tell screenreaders to ignore the semantic meaning of tags, so tables need them because tabular data like graphs require all of the column and row information for people to properly navigate and understand them. In email, developers often rely on tables for presentation instead of tabular data, which is why tables require this. DIVs, on the other hand, do not have a semantic meaning that would need to be overridden for screenreaders.

For clients who insist on using image-based emails, are there best practices we should follow?

Bettina: This is a tough one! There are countless reasons why sending all-image emails is a horrible idea. So as a first step, do whatever you can to convince your client that this approach comes with a horrible subscriber experience. Our blog post on Why You Should Not Send Image-Only Emails has lots of insights and tips to help you make your case.

If there’s no way to get your client on the right track, then all you can do is to optimize your image-off view with ALT text (you can even style that ALT text) and use bullet-proof buttons so that at least your CTAs still work when images are disabled.

Does the use of web-fonts impact accessibility?

Alice: From a code standpoint, it shouldn’t. From a design standpoint, it means that you should always make sure that both the web-font and its web-safe fallback meet contrast ratio standards to be readable. For example, if your web-font is thicker than the fallback, just make sure the fallback also passes contrast ratio scores since the fallback is what users on, say, Gmail, might see instead.

The one change we haven’t made in our code template is using the semantic element for headings or paragraphs. We currently stylize the table cell for the text. What issues can this present for accessibility?

Alice: I’m presuming that the table wrapping the text already has its role set to “presentation” or “none” to curb any unnecessary screenreader noise. So other than that issue, not using correct heading/paragraph tags would present a navigational issue for assistive devices, as some technologies allow users to skip from heading to heading (and its related paragraphs) as if it were a table of contents.

Can special characters, such as curly apostrophes, quotation marks, ampersands, etc., be read by screen readers?

Alice: It depends. Ampersands are often read out as “and”. Quotation marks and curly apostrophes are ignored like how someone might not pronounce them while reading something out loud. Other special characters are considered case by case, like bullet points are read out as “bullet”. I would generally recommend always testing to be sure.

Any suggestions on formatting text only for accessibility? I use several “=” or “-” breaks between sections. How are those handled?

Alice: Dashes and underscores don’t tend to be read out, so those are fine. However, screen readers will read out the “equals” sign, so I would recommend avoiding it.

Bettina Specht

Bettina Specht was the Senior Content & Lifecycle Campaigns Manager at Litmus

Q&A