JMCommunity Contest: Creating an Accessible Email
Email designers and developers are becoming more aware of making sure their emails are accessible to everyone, by ensuring there’s enough of a color contrast between text and background colors, using ALT text, and employing semantic HTML tags in the code.
It’s been a popular topic of discussion in the Litmus Community in the past a few times, and more email developers are championing accessibility in email.
For this month's Community Contest we want you to create an email, using as many tactics as you can, to make it as accessible as you can. The design is totally up to you—it can be as simple or as complicated as you like. As well as the email, give us a little explanation on how and why it’s accessible.
The email doesn't need to be built exclusively for this contest—you can use something you've already sent/designed. And you can enter with multiple emails, but it only takes one to win!
Prizes:
- $50 Amazon gift card
- 2 free months of Litmus Plus
- A Litmus care package (t-shirts, stickers, etc.)
- A print copy of Modern HTML Email by Jason Rodriguez
To enter simply share your entry as a reply in this discussion. The easiest way would be to create the email in Builder and share your code via Builder.
The contest is now closed.
Feel free to keep posting your most accessible emails—we love seeing them.
Congratulations to the winners Paul Airy and Chris!
Every one of the emails entered into the contest were amazingly well thought out and we loved seeing how accessibility was incorporated into different aspects of the email.
Thank you to everyone who participated—keep on flying that accessibility flag in email.
Hi Jaina,
Here’s my submission for the Community Contest – Type E: 07. The Mobile Issue.
https://litmus.com/builder/af97b12
In terms of features, there’s some standard ones, and some enhanced ones.
STANDARD
Structure:
• The emails language has been declared in the html attribute, so that screen readers know how to read the text.
<html lang="en">
• The emails character set has been declared, so that the characters are rendered correctly.
<meta charset=“utf-8”>
• The email’s been structured using <div>s. ‘Ghost tables’ have been used for the benefit of Microsoft Outlook, but in all cases role=“presentation” has been applied so it doesn’t force the subscriber to work through the <td>s.
• The email follows a logical reading order from top to bottom.
Imagery:
• alt attributes have been included on all images.
• No title attributes have been used.
Typography:
• All text is ‘live’ (no text has been embedded within imagery).
• All typography is semantic – one <h1>, multiple <h2>s, <h3>s, <h4>s and <p>s.
• style="margin:0;” has been inserted into all opening semantic tags, to prevent excessive spacing being applied around them by the email and webmail clients.
• The font-size of paragraphs of text on mobile have been enlarged to 16px, triggered by a @media query.
• The line-height of paragraphs of text on mobile have been enlarged to 24px, triggered by a @media query.
• aria-hidden=“true” has been used to hide visual content (illustrations and captions) from screen readers.
• Colours have been carefully selected to ensure there’s sufficient contrast, and tested using the WebAIM Contrast Checker (http://webaim.org/resources/contrastchecker).
Interaction:
• The Accessibility Switcher™ has been implemented, to enable subscribers to choose from standard size and large size text views (on supported email clients).
• The button is fully selectable wherever it is touched or clicked (edge to edge).
• Link text is contextual within the paragraphs (no use of click here).
ENHANCED
Interaction:
• By either choosing from an ‘Accessibility Option’ when subscribing to Type E: or updating their preferences from a link in Type E:, subscribers can now choose to include tinted backgrounds in their Accessibility Switcher™. This is an opt-in feature, driven dynamically, and as such is only served into the email and webmail clients of those who request it. The ‘Tinted Backgrounds’ option features:
– Yellow, blue, green and red tints, designed to assist those who struggle with white backgrounds, such as those with Dyslexia or Alzheimers.
– Text links are bold have had their underlines removed to assist those who struggle with underlines.
– Distracting backgrounds have been also been removed.
This is awesome Paul!
One possible addition you could do is add
tabindex="0" role="button"to the<label>tags you use in the Accessibility Switcher™ so you can select and click them just using the keyboard.Thanks, Mark!
This is really well executed and well documented. Thank you for sharing.
Two questions:
1) Does the <div> markup structure render well across all non-Outlook clients? I have been unsuccessful with this and reverted to <table>s. If so, what about more semantic elements?
2) Your CSS ends up being 18,319 characters. Doesn’t Gmail then strip the entire <style> element?
Thanks, Charles!
1) Yes, the <div> markup renders as well across all non-Outlook clients as <table> markup. I’ve experimented with other semantic elements, such as <caption>, but they’re not supported at the moment.
2) Gmail has retained the <style> element, in spite of the number of characters.
https://litmus.com/builder/d531cdf
I thought I would share this email that came about due to a glitch in our ESP.
An event invite went out to each of our 200k records 19 times within the course of an hour. I managed to respond with an apology haiku that gathered a tremendous amount of social media buzz and we ended up increasing event registration by 20% compared to years prior. Some people who didn't have us on their radar at all, ended up enrolling into our full time program - though hopefully it wasn't just this email that convinced them.
We didn't try to push any call to action, since they received 19 of those already, and we didn't need to decorate it with html...we just wanted them to hear our apology.
I love this – the story, the product and the result. Thank you for sharing.
Hi,
This is my first post on the litmus community and I love the push for accessibility in emails. It has been a goal of mine to make our emails as accessible as possible.
The email I am submitting has been re purposed for this contest.
I had written all about what makes this email accessible. But to keep it basic:
• Defined language on Html tag
• Used UTF-8 for the support of multiple languages, alternatively I have also used charset=ISO-8859-1.
• Followed Semantic order
• Used the role=”presentation” on all table.(wishing ARIA get more support soon)
• Passed colour contrast checks (Although that blue background and white text was tricky)
• Avoided opening links in new tab for people with cognitive disabilities
• I avoided using the title tag for links as I have read there can be more harm the good that can come from it. Also JAWS was the only readers I was able to figure out how to get the title tag to work.
• Kept the language of the email clear and simple
• Used an off black for part of the copy
• I used the abbr tag for the word acronym CBA (Acronym tag no longer supported with html 5)
• Used alt text in the image as well as stylized them for people who have images turned off
• Ran through chromevox and spectrum to get an idea how a screen reader would read the blast and check the colour contrast with certain colour blindness.
Any feedback from the community would be beneficial, I can also provide more details if needed.
https://litmus.com/builder/64406c8
Side note: I do know that using all caps in text is not good as people can have a hard time reading it and some screen readers may read each individual letter separately. I did this as I wanted to avoid having the text within the logo.
Hey Jaina,
Thanks for making a contest for Accessibility. I used to work at a tea company where we had a regular that was blind. She talked to me about how frustrating the company's website was, because it didn't use any accessibility features at all. Her frustration impressed on me to strive to make my code better and easy to understand for all audiences. Now with the Association, it's one of our goals and so we really push for accessible friendly email.
Accessibility Features
https://litmus.com/builder/9419c9f
Thank you for this great example and the story behind rising to the occasion. While it achieves the intended goal of being accessible, I would like to point out a couple of items that may improve it.
First, technically, UTF-8 does not set the language. It simply sets an octet encoding protocol on the characters within the document – which can include many foreign alpha characters. Try adding the lang="en" attribute to your <html> element to ensure that language is actually set on the document.
While 16px is an improvement over most, I would encourage everyone to consider that the smallest size in any viewing context. Apple, Google, Microsoft and others all publish great user interface guidelines that suggest larger type. Most agree that type size should be based on posture (distance from screen) over screen size, but the net result of that measurement is that text should be larger on a handheld device than a laptop or desktop.
Finally, I would remind everyone that #a11y is not limited to simply supporting screen reading utilities for the visually impaired. Universal design is literal. All humans and all contexts should be considered. For example, an area often overlooked is cognitive ability and reading level. Avoid jargon and phrases that may not be universal.
Great job on implementing a robust list of considerations.
Thanks Charles for clarifying the difference between UTF-8 and lang="en"
https://litmus.com/builder/2a59caa
Hi Eyal, thanks for your submission. The email looks great—could you tell us a little about it and what makes it an accessible email, in your own words?
Hi Jaina -
This Email used to be an internal corporate Email for all RAPP employees across the globe, reaching remote offices to share recent updates and news about RAPP.
The Email I've shared here is a succinct version but has all the goodies of an ADA-compliance and mobile friendly HTML Email.
I used the following techniques to make this accessible and legible on every major Email client (yes, including the infamous Outlook 2010/13):
Thank you for looking, please reach out with any question :)
https://litmus.com/builder/e5103b3
I’m so happy accessibility / #a11y is getting the focus it deserves within email, I push quite hard within companies to make small changed to make e-mails more accessible. I coded this last year for a train operator and have altered the Design, hero, code and Content to make it more accessible.
Some features:
Language English
Presentation=role on main table
Correct natural tab order and keyboard focus
Outline not removed from focus
Colour contrast that passes at least AA (sometimes AAA)
User can naturally increase text size to 200% without breaking.
Animated GIF that stops after three cycles / within five seconds
Sentence case copy throughout to cater to users with cognitive issues like dyslexia (no ALL CAPs, only brand names get each word Capitalised)
Live text for buttons with contextual copy for links
All fonts, including terms text minimum 16px.
No change in link behaviour with _blank tags
No title within links (it’s often better to remove these)
Descriptive alt text
Styled alt text (for users with no images)
Large buttons, especially on mobile where these are full width to cater for user with motor issues
Semantic markup, h & p tags
Correct social icons (not custom for consistency)
More RWD techniques but aid accessibility:
High-density images
Content removed on mobile (menu, main text cut down to make it more concise for smaller screen)
I would also include a plain text version
I toyed with changing the Hero image further to remove the text, as ideally for accessibility no copy should be within an image. However I weighted up the benefits of having an animated gif and decided having the styled alt copy and it stopping after there cycles was a nice comprise.
There are many great examples being shared. There are also a few unexplored opportunities. The net result is that there is a large volume of discovery and key learning along the way. It would be wonderful to publish a comprehensive list of DOs and DON’Ts following the contest. Perhaps a collaborative document on GitHub?
Here is another great resource form Maarten Lierop and Jordie van Rijn:
Accessibility tools for email developers
“With the current maturity of the channel, it should be totally possible and new devices, email clients and coding techniques demand better accessibility. We believe it is the right time to get more serious about the topic to keep the channel open for the future.”
I think this would be a great idea and happy to help with this
It looks like @omgitsonlyalex just did. Here is the post on Email on Acid Blog. It’s a very good start. I can already think of dozens of additions.
Agreed, great blog. Continuing on this list would be a great idea.