Guide to testing emails with a screen reader
This article is written for those who are interested in using a screen reader to test emails and develop a better understanding of the experience some of their subscribers may be having. This is not intended for learning how to use a screen reader to fit your own assistive needs there will be better more detailed articles about that, however, you are still welcome to read on if you like.
Most operating systems have a default screen reader built-in:
Screen reader: VoiceOver
Where to find it: systems settings/accessibility/VoiceOver
Screen reader: TalkBack
Where to find it: settings/accessibility/TalkBack
Screen reader: Narrator
Where to find it: settings/accessibility/Narrator
However the 2 most popular screen readers according to the WebAim Screen reader user survey are
- JAWS - Only available on Windows. This is quite expensive however you can download it and use it for free but you’ll be limited to 40mins at a time.
- NVDA - Only available on Windows. NVDA is free to use although we do recommend giving a donation to help them keep up the good work.
I would strongly recommend starting out testing with a desktop screen reader, these are easier to use, and if you get lost, you can still use the keyboard and mouse as you would without a screen reader. Using a mobile screen reader changes the tap and swipe actions. The first few times you use it you may find it hard to get back to the settings page to turn it off.
The controls and shortcuts vary for each screen reader but Deque has a great set of guides for screen reader shortcuts and gestures. The first thing to do is find the guide for the screen reader you’ll be using and start getting familiar with some of the basic controls to around the screen.
Much like when testing email rendering, I like to start off accessibility testing in the browser to make sure everything works before the email client quirks come into play. When doing this I find it easier to open the preview in a new tab (if you are on a pro account) or open a share link (if you are on the community plan) this reduces the non-email content on the page which makes things a little easier to navigate.
- Check the overall content. Navigate top to bottom and make sure everything is read out correctly, in the correct order and no content is skipped. Make sure that any alt text is giving enough information and check semantic elements provide all the information they need.
- Check the headings menu. Open the headings menu, check that each heading is present in the menu, gives enough information to describe it’s content, and check the order of headings is logical and not skipping down any numbers.
- Check the links menu. Open the links menu and check that each link is present in the menu, and that the text for each link gives enough information to allow a user to understand where the link will take them and make the choice if they want to visit it.
When you are new to screen reader testing it can be hard to know how things should sound. So I recommend testing some examples of well-written accessible code and comparing that to your own code. The W3C Web Accessibility Initiative (WAI) have some very good web accessibility tutorials that I reference often.
In the same way that every operating system is different, every browser is different, and every email client is different. Every screen reader is different too. Just because something is true in one, it doesn’t mean is true in all of them. Yes, this is frustrating!
Ideally, we’d test every combination for every email, but that’s not really practical. To start with I’d recommend picking an email that you feel is representative of your work and thoroughly testing it in at least 2 screen readers. Any issues that come up here will quite likely be repeated across a number of other emails so you can often pick up a lot of fixes from one place. Try to repeat this in-depth testing periodically along with other tests to make sure everything is in good working order. Each time, try changing things around, a different email, screen reader, browser, email client etc.
Then also, add screen reader testing to your regular testing workflow you use for every email you send. This could be just a quick 5-10min test to pick up any obvious issues but even that can make a big difference.
As you do more and more testing and get more comfortable using a screen reader, try covering the screen so you are only using the sound. This helps to stop you from unconsciously filling in, and context from what you are seeing. Also, try this with emails that you have not seen at all, this could be something created by a coworker or maybe something hitting your inbox. Navigate it with the screen reader, then look at it on the monitor. Look out for any extra information you are getting from the screen that was missing in the email and learn from it.