Alert:
Interactive Emails and Accessibility – Part 3
Welcome to the last part of my 3 part series on interactivity in emails and our limitations in creating interactive accessible emails. In Part 1, we talked about conformance and in Part 2, we went over our biggest problems: Keyboard access and labeling. This week, in Part 3, we’re going to get into a lot of nuance. Don’t fret! I know that as humans we want simple – and the simple answer here is just not to use interactive components 😀but in order to understand the reasons why we can’t have interactive emails we’ve got to really dig in.
And I’m going to just say it plainly here: Some of these might feel too nuanced. As email marketers we have a very MacGyver-esque approach to problem solving – likely fueled by too much caffeine and hard deployment deadlines. We make it work and if we can’t make it work we… still make it work. But that’s not what accessibility is. Each of the WCAG failures and ARIA attributes we’re talking about in this post are incredibly important. They have been researched and defined to be the best solution possible and standardizes experiences so that assistive tech users can easily navigate complicated content. These aren’t “nice to haves” they’re “have to haves” – so don’t blow them off as not being important! So – let’s move on to our next problem –
Problem #4: No Funny Business
This one can be tricky – if you’ve taken the Trusted Tester, this section is probably one of the harder ones to distinguish in the testing. (soo many tears!) But I’m going to walk you through this and hopefully you’ll be like, “that’s so easy!”.
There’s a part of the WCAG that talks about being predictable and there’s two big ways that our interactive content can be unpredictable – SC 3.2.1: On Focus (Level A) and SC 3.2.2: On Input (Level A). Again, these are Level A conformance criteria meaning that if you can’t meet this criteria you’re not even baseline accessible.
These are obviously different criteria but they both have a similar underlying theme where we don’t want to surprise our users with interactions that are not expected. So examples of failing these criteria would be:
- On Focus: You navigate to a progressive disclosure accordion (you know the things with the + sign that opens more content) – but instead of opening the accordion with a mouse click or return, the content automatically opens on focus (or hover). This is failing 3.2.1 because a user is going to suddenly find themselves activating something they weren’t intending to activate – because hovering/focusing on an element doesn’t usually open content.
- On Input: You select a form radio button and a new window pops up unexpectedly. This is failing 3.2.2 because that is unusual behavior for a radio button and the user didn’t expect the sudden change of content and navigation.
3.2.1 On Focus is definitely a bigger offender and really just shouldn’t be used. If you’ve created an interactive element that relies on hover or focus, it’s not accessible. Also noting for the purists: there definitely is a difference between focus and hover but that’s beyond the scope of this convo.
3.2.2 On Input has an option where you can do this if you tell the user it’s going to happen first. So in our interactive email switch that changes all of the content under the switch, you can pass this part of the criteria by adding a note or instruction about what action will happen. (It’s still not accessible though – you’re just meeting this one criterion.)
This gets a little complicated because what is “expected” vs “unexpected” – do we have to start spelling out to users that they’re about to encounter a link that will go to a different page???
No – because a link is a semantic solution that makes up the common structure of digital content. This is also part of why we focus on semantics so much! The screen reader already tells the user that this is a link and the user already knows they’re going to go to a new page because that is a common experience on an email.
So to a certain extent when we’re talking about accessible interactive content you really have to dig into what the different expectations are for interactive content. Luckily the W3C has an ARIA Authoring Practices Guide that goes into super deep detail about how all of these interactive elements should work, using what keyboard commands, etc. It’s honestly a treasure trove of helpful content that will keep you from spending years chasing around “expected” vs “unexpected”. Hooray!
And that leads me to the final problem:
Problem #5: You can’t use Javascript
If you went off the rails just now and dove headfirst into the ARIA Authoring Practices Guide you might have noticed that near the bottom of each interactive pattern example it talks about any relevant ARIA states. Reminder: ARIA has very little support in email. But that doesn’t even matter because we can’t even get this ARIA states thing into inboxes to test whether or not it’s supported because… Javascript.
First – let’s talk about ARIA states. If you remember, ARIA attributes are bits of code we use in our emails that specifically “talks” to assistive technologies to give them additional information about our content. An ARIA state is something that tells the user the state of the content – like if your menu is open or closed or whether your checkbox is checked. Those really are the two most common ones we’d use in email… if we could.
The problem is – the state is a specific experience related to that specific object. The thing we would use an ARIA state attribute for can’t change in email the way it does in the web world because this must be done using Javascript. The state cannot change with HTML/CSS only.
So we can’t tell our users that the menu bar is expanded or not, or that the hot spot window has opened or closed, or that the switch has been activated or not.
Essentially the problem here is that we are not using semantic solutions here. Most (if not all) of these interactive components are using a “checkbox hack” where you’re using a checkbox waaaayyyy outside it’s semantic purpose (ie. selecting options from a form). Remember when I said we could use ARIA when we can’t use a semantic element appropriately? That’s why we would normally use the ARIA states in these situations, because it would help assistive technology users better understand what was going on when the normal semantic context was missing.
BUT – we can’t change the ARIA states without Javascript. We just can’t.
AND – we can’t use Javascript in email.
(You should already know this, it’s a security measure taken by every email client and most ESPs won’t let you send with Javascript anyways so it really is just not going to happen)
So any of the interactive elements you could squeeze down through Problem #4 absolutely hits a brick wall at Problem #5.
When I’ve explained to folks that we can get almost to fully accessible they see dollar signs. 🤑
But here’s the rub: Almost is not good enough.
And I don’t mean that in some kind of utopian perfection kinda way. Those ARIA states are really important when we’re using this checkbox hack. It’s really the only way to make these solutions accessible.
People using screen readers will not know how to interact with your switch and drop down menus. If they open a hotspot window they will not know what just happened.
It also means you can get sued for having inaccessible content because… this is inaccessible content.
It also means that if your boss or client hires an accessibility consultant or uses their accessibility team to review your email – it will not be accessible.
Note: In the “Switch” pattern of the APG, we have a note about using an HTML button to control these switches and how we then wouldn’t need to control the ARIA states. It’s important to note what it’s not saying – it is NOT saying “You can do this all with HTML” it is still using Javascript to change those states for assistive technologies, it’s just using HTML to create the switch/checkboxes.
Problem #6: Email is still Stupid
Getting even problems 1-4 to also work across different email clients that support interactive content is super challenging. If you can get it to work on your personal devices and assistive technologies – it often will not work on other combinations and that gets really really tough.
Just from a testing perspective that means you need at least an iphone, ipad, android, PC and macbook. And then you have to learn how to use various assistive technologies (or at least screen readers) on each of those devices. That is expensive and time-consuming – ask me how I know.
So the inherent cost of rebuilding these interactive components and testing them thoroughly enough to ensure they work on most email clients and AT’s is just super high. It’s not an impossible problem to solve, and to a certain extent we can never test every single thing in every single situation – but we also can’t send interactive components out if we don’t know how they work for assistive technologies.
Conclusion: Then what do we do now??
Big ole’ whopping disclaimer here: These interactive components cannot be accessible.
(I keep saying this because I just know someone’s going to misquote me or take these things out of context)
I don’t want to give anyone the impression that they can be accessible or that “almost” is close enough because it absolutely is not.
The purpose of this post is to help you work through the how’s and why’s of specific accessibility related issues as it relates to interactive emails. Basically so that you can test against these problems to make sure whatever new component you’ve been told is accessible, actually is. So absolutely none of what I’m about to say will change that these interactive components are still inaccessible.
I think that we can and should make updates to our existing interactive content to solve problems 2, 3 and 4. Get that keyboard access under control and do the hard work of locking down the info and relationships part too. Don’t surprise your users and keep your content as predictable as possible.
Do your very best with what you can control while also advocating for different solutions with your decision makers.