In this Q&A blog post we talk to Mark Robbins, Interactive Email Specialist at Salesforce and creator of Good Email Code. Mark is a strong advocate for accessible emails, as an early adopter we wanted to ask him questions around its relevance and importance within the email channel.

"Using semantic code where possible, makes a big difference."

Hi Mark, what inspired you to start looking deeper into accessibility and how it applies to the email channel?

My interest in accessibility started when I first saw a talk about it. What clicked pretty quickly for me, was the idea that if your emails aren’t accessible, they are broken. I had put in a lot of time and effort developing my code to make sure it worked in as many email clients as possible, so the idea that it was broken hit me quite hard. I needed to fix it. 

Also I’m dyslexic and for me reading is a big effort, so I know first hand how small changes can make a big difference. When I’m reading and I get to the end of a line of text, finding the start of the next line can be tricky. If the text is left aligned the next line starts directly below, that makes it easier, but if it’s center aligned I can get lost. I can also get lost if the line height is extremely large, but then again if it’s too small the lines run into each other.

Sometimes to help with reading, I will click on a paragraph to highlight the text and help keep my place when I’m reading, or i might click on a word I don't know to look it up. But this doesn’t work if the text is an image or if it’s wrapped in a link.

Why do you think it’s so essential for Marketers to be adopting accessible features within their emails?

There are a lot of good arguments for why improving accessibility is a good thing.  Generally speaking most accessibility improvements have benefits for all users. But specifically talking about users with disabilities I like the three part argument of moral, financial and legal.

Moral. If you’re sending content that certain groups of people can’t consume, then you are discriminating against them. Everyone should have the right to engage with the emails you send if they want to. Morally, it’s the right thing to do, but this is often met with a response of not enough time and money to make improvements. So then we look at financial benefits.

Financial.  If people struggle to consume and engage with your content they are less likely to give you their time or money. In some cases it can actually be impossible for them to give you their money even if they still wanted to. Financially it’s the profitable thing to do. If there is still push back then let's talk about legal obligations.

Legal. If people can’t consume your content and can’t assess your products or services and you’re not trying to fix those issues, that’s discrimination and that is against the law. In the UK it’s the Equality Act, in the European Union it’s the European accessibility act, in the USA it’s the Americans Disability Act (ADA), in Canada it’s the Canadian Human Rights Act and there are many more laws around the world. It’s even covered by the United Nations Convention on the Rights of Persons with Disabilities (CRPD). Legally it’s the required thing to do.

So from a priority point of view, it’s a question of how much you’ve done already. If you’ve done nothing then get started ASAP. After that it’s an ongoing job, it needs to be built into your email creation process. You probably already make sure your emails work for users with different email clients, it’s just as important they work for users with different accessibility needs.

What are some quick wins for email developers?

The number one thing is testing for accessibility, if it’s not already part of your QA process then add it in. This will flag up a list of issues that need fixing. Using semantic code where possible, makes a big difference. Good use of headings, lists, landmarks, etc can add a lot for a screen reader user or reader view user.

Where you are not able to use semantic code you can fix that with role and aria attributes. But be very careful here as I’ve seen a number of occasions when a well meaning developer has ended up making accessibly worse by using these without fully understanding them. A good use of role is where sometimes we have to use tables for layouts in email, tables have a semantic meaning, this can be very confusing for a screen reader user being told they are in a table but it’s actually just a paragraph of text. We can remove this semantic meaning by adding role=”presentation” and this will remove all the extra unnecessary information.

Think about your typography, avoid small fonts and keep good spacing. If you have more than 2 lines of text in a paragraph, make sure it’s left aligned, assuming it’s a left to right language and if you have more that one line make sure there is sufficient line-height, I tend to use 1.4em or 1.5em. Also remember paragraphs will likely break onto more lines on mobile devices.

Think about colour contrast, make sure your text stands out against your background. Also try and keep backgrounds solid and avoid background images unless you test them thoroughly. The list goes on and accessibility can seem like a huge daunting project, but doing something, anything, even something seemingly small, can have a big effect. So do one thing today.

How can email developers use relative units instead of pixels?

Any time we set a size we have the option of what units to use, these can be absolute or relative. Absolute units like px(pixels), cm(centimeters) or in(inches) will always be the same size. Relative units can change as they are relative to something else. The 2 I’m interested in for accessibility are rem(root font size) this can be set by the user via the OS, browser or app, and em(current font size) this will inherit from the parent element.

From an accessibility point of view this is helpful as it means we can respect the users preferred font-size. If they want a larger font we can give it to them, absolute units can’t do that. Unfortunately rem units don’t yet have full support across all email clients however em units do work everywhere so we can use those. Em units inherit from the font-size so if our default font-size is 16px then 1em = 16px and if we now set the font-size to 1.5em it will render at 24px, if we were to then set a margin:1em on that same element that would also render at 24px because we’ve updated the relative value.

So to take the users preferred font-size we set the wrapper of our email to be font-size:1rem and now 1em is equal to 1rem. To add a fallback to the email clients that don’t support rem units we can include font-size:16px and we can enhance it further for email clients that have a particularly small default rem value (like Applemail) by setting a minimum value using font-size:max(16px, 1rem) so the full code looks like this font-size:16px; font-size:1rem; font-size:max(16px, 1rem).

If you are setting your font-size using relative units then it’s essential to also set the spacing around the text using relative units, this include line-height, work-spacing and letter-spacing, also if you are setting padding or margin between text that should be included. You can also set any other padding, margin, border, height, width etc. using em, you can even use it in media queries. Anywhere you set a px value you can use a em value the one exception is VML elements.

Finally, what piece of advice would you give to marketers who are thinking about making their emails more accessible?

Email rendering bugs are often easy to spot, you can see when the screenshots in your testing tool looks different to the design you’ve been given. Accessibility bugs are much harder to find unless they affect you directly. To get around that we need to learn how to test, find and understand accessibility bugs. As a starter I’d recommend installing the axe and wave browser extension, these can flag up a number of issues.  

Also using the browsers built in reader view or a reader view extension can really highlight the good or bad use of semantic code. As well as checking the experience for people who use reader view, this also highlights issues that may affect screen readers and a number of assistive technologies.

Browser dev tools have a number of accessibility tools built in.  Colour contrast is a very common one, click on a colour and see if it passes WCAG AA or AAA standards. If you want to take that further and understand it more about issues behind colour contrast I recommend looking at whocanuse.com. With these and any testing tool, use them as a guid not as a fact. Just because something passes, it doesn't guarantee it’s accessible for everyone. It’s always good to try using some assistive technology yourself too.

A good starting place is keyboard testing. Try using your computer for a day, an hour even a couple of minutes without touching the mouse. This not only tests for keyboard users, it's similar to how some other assistive technologies work. And as an added bonus you can now use your computer while drinking a cup of tea.

Mac OS, iOS, Windows, Android, whatever device you use, they all have built in accessibility tools these days. Try some zoom controls, try using a screen reader, it takes some getting used to but it can tell you a lot. This all may sound like a lot of work, and it is, but you don’t have to be an accessibility expert overnight. Start with something small and build from there. It’s about getting into the mindset of thinking about accessibility and the rest will come with time. Also don’t be afraid to ask for help, if you're in the EmailGeeks Slack community join the email-accessibility channel and post some questions.

At ActionRocket we can help you to understand more about accessibility and how it affects your email audience. Our aim is to get every brand to be creating emails with accessibility in mind. If you think your emails could be more accessible we’d love to help, get in touch with us at hello@actionrocket.co.