Last week we hosted a webinar all about Accessibility in Email. I think it's safe to say that the webinar was a resounding success. We were truly touched to see so many email folks interested in accessibility, thank you if you did attend - it meant a lot! This is a topic that is extremely close to our hearts and having the possibility of sharing it with you is why we do what we do.
Missed the webinar?
Accessibility is all about making email inclusive to everyone. For that reason, we're happy to share the recording with you from the webinar.
Questions and Answers
We were absolutely thrilled to see how many questions came pouring in. Not only does it require us to think about answers, it's gives us a chance to truly answer your burning questions. With that being said, we had so many questions that we couldn't get to them all! We've pulled out some of the most popular questions and answered them below.
Q: Do you need to add the role="presentation" to each table in the email? Just the highest level table?
You'll need to add role="presentation" to each table. It shouldn't take long at all!
Q: For avoiding center aligning - is that only for body copy? or titles/headings too?
We recommend avoiding center aligning any bodies of text, yep - even on mobile, however titles and headings are okay to be centre aligned, just make sure to consider your logical reading patterns.
Q: Would you consider text, rendered as an image, with appropriate alt text coded behind it, be a valid use case for accessibility? It would be easily able to be zoomed in on and read by a screen reader.
This is a great point. We completely understand that you can't always avoid using images in emails. However, where possible, we would advise to keep text rendering as text, rather than an image. I would consider the best practice to be a background image with text on the top. For some advanced techniques, we know you'll need to use images rendered as text. Just please ensure you're properly using Alt Tags.
Q: Email pretext header: Does this replace "See online version" link or is it somewhere else in email?
When we were referring to preview text in the webinar, we were talking about the text that we put in above the View Online link. It is text that is completely hidden from the email, it is simply there to render content to compliment the subject line in the inbox. We always advise having a View Online link visible.
Q: Does VoiceOver take the same queues as Siri when reading emails?
Brilliant question. This is something we're doing a lot more research into. It would be a fair to assume it would take the same queues, however as you probably know, assumptions in emails cause errors. We will be doing more research into both Apple based voice-over tools, and others.
Q: Have you done any tests using ARIA?
As of latest checks, the only ARIA role we recommend is presentation. We cover why in this blog, but a short answer is that Webmails will all use ARIA roles inconsistently. Hopefully, in the future, we will have more uniform support and can start using ARIA for all things email.
Q: What impact does using proper markup have on accessibility? IE: Using h1 tags for actual headers instead of a span or p?
Lots! Thanks for bringing this question up. We really should have covered this in the webinar, so apologies for that. We recommend always using the semantic code tags you asked about. These tags allow the screen reader to properly differentiate between headings and paragraphs not only creates a more pleasant reading experience, it allows the user to navigate through your emails.
Q: Need Clarification: Using titles for the entire HTML document are OK, just not titles within images (for rollover effect)?
We had a lot of questions about titles and how to use them properly. I will point to this amazing article by the A11y project, which breaks down how to properly use titles.
Q: The WC3 specs can be hard to interpret regarding animated GIFs. What are some best practices you've found for animated GIFs?
Another amazing question. I agree, the specs can be very hard to interpret. Although it's a few years old, this presentation is a great resource for considerations when using animated GIFs.
Q: This is fantastic! I have gotten a lot more conscious about alt text, also as an added promotional item and for the "fun" factor. Having said this, there are a lot of things I have not thought about. Having a daughter with ADHD, I never thought of the way she reacts to pages. Good food for thought. Any more resources you can share?
So glad you enjoyed the webinar! I really like these posters produced by the British Government for some quick, easy advice for accessibility.
Q: How would you suggest revising content so that it's not overwhelming for people with ADHD?
For a first step in making your content more ADHD friendly we suggest:
- Maintain a logical reading pattern that is simple to navigate
- Avoid disruptive imagery, make sure your images compliment your messaging and content - design for the sake of design is mess
- Avoid over-the-top animations and animated GIFs, consider if you truly need an animation to loop continuously
- Avoid subtle, ever changing animations. These can draw attention away for sustained periods of times
- Consider condensing your content down to key points.
Q: If your image content is represented in the visible HTML text, do you also need to include it in the alt text? Or is it ok to be more general?
If your image is already represented in visible, readable HTML text and the image is purely for decorative purposes you can put a blank alt tag on there. Simply add alt=" " and this will tell the screen reader that the image is decorative and thus, will skip it in the reading process.
Q: Define image only emails? What would you recommend besides an image only email?
When we talk about image only emails, we're generally referring to emails that are compromised solely of images. These emails are still very prevalent, with the retail industry being the biggest culprit. We recommend keeping key content to text, rather than rendering it as images.
Q: Are pre-headers intended purely for siri's email preview, or are they also read by a screen reader after the email is opened as well?
Preheaders will cover a few things for us, primarily they allow us to provide a bit of extra info for people in their inboxes. They also help us provide information to Siri and other such devices for a breakdown of the email before a user opens it. Once an email is opened, a screen reader should not read your preheader text, as it is hidden from view.
Q: How accessible are plugins like LiveClicker or Moveable Ink (for example countdown timers)?
It's my understanding that these tools use primarily images. So, by default, they won't be quite as accessible as using an HTML solution. That being said, I do not know of a purely code solution to countdown timers. If you are going to use something like this, ensure you're properly using ALT tags.
Don't guess - test!
Want to give Email on Acid a try? We offer a free trial, free for 7 days, so you can see what we have to offer. Because every client renders your HTML differently, it’s critical to test your email across the most popular clients and devices.