Alert:
Interactive Emails and Accessibility – Part 1
TLDR; I’m not including a TLDR’ because I really just want you to read the whole thing because this issue isn’t straightforward enough to boil down to a few sentences. So please read <3
A year or so ago, I had a client that really wanted to push the envelope into accessible interactive content. Because of their industry they had a very strict accessibility team that wouldn’t let your typical interactive email content get approved and they wanted me to really dig into it and find out the details and see how close we could get to real accessible interactive content. (It was super cool – someone paid me to do my favorite thing!)
It was a bit outside my wheelhouse, honestly. I have learned a lot about accessibility over the last few years but because I know that most, if not all, interactive content is inaccessible, it became a real barrier for me to dig too far into it. I mean, there are people that are way better at interactive email coding than me and it’s pretty rare for me to get that kind of project over an accessibility project. Don’t get me wrong – I can code a mean hot spot with the rest of them, but I wouldn’t have ever considered myself a go-to interactive email coder. I can do it, but it’s not really my bag.
All that to say – I had to call in reinforcements after doing a lot of digging so I called up one of Oracle’s accessibility specialists whom I’ve worked with a few times before. I had a handful of calls with him to get more details and to check in whenever I worked out a solution to whatever problem I had discovered with his support.
And since unveiling my accessible slider solution, I’ve had a number of folks ask me for more details on it (or to review their ripoff of it – 🙄) and I’ve had a few of my quotes be taken in different directions than I intended – so I’m going to be super loud here:
Current Interactive email solutions cannot be accessible.
My slider withstanding, I have not seen a single accessible interactive email element. I have dug into this topic and picked apart numerous examples of interactive content and it just can’t happen and I wanted to break this apart so that you can either do your own digging or review purported solutions for yourself.
Note: I’ve prioritized this list from most critical accessibility problem to least critical. If you solve the first couple of problems you will be creating a “more” accessible solution, but it won’t meet all of the parts of the WCAG so it won’t actually be accessible.
Meaning: someone with a disability still won’t be able to access your content and you would still be liable for that problem plus if your client hires an accessibility consultancy team they will call out this problem!
So the best we can get is almost, but definitely not, accessible.
Problem #1: Conformance
In the WCAG there is a whole section about conformance and all of the different ways digital content needs to be accessible. Conformance Requirements 4 and 5 are part of this section and it’s… complicated. I’m gonna do my best to explain them here but I’m probably a little rough in spots. Essentially the WCAG gives us these two ways for us to include content that is not *completely* accessible so long as we don’t wreck someone in the process. It’s definitely not accessible – but it’s not causing severe, life-altering problems for folks.
Requirement 4 says “Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported.”
So to that end – if you include inaccessible interactive content in your email, you’re okay to do that so long as that content is also available in a way that is accessible. (you also have to meet Requirement 5 so slow down)
Hooray! We solved it! Except… I want you to think about this a bit. In email terms we would need to have the interactive content and essentially the fallback in the same email. I’ve not yet met a designer that’s okay with that and your average recipient is going to think the email is broken. You’re also going to run into some issues with hierarchy and order if you try to make it less bothersome by moving the fallback sequence to the bottom of the email or something. (I know how sneaky you guys are!)
And that’s only one part of this requirement because 4 and 5 are intrinsically linked.
Requirement 5 is all about Non-interference: If you have stuff that’s not accessible in your content it MUST meet these four criteria:
- 1.4.2 – Audio Control,
- 2.1.2 – No Keyboard Trap,
- 2.3.1 – Three Flashes or Below Threshold, and
- 2.2.2 – Pause, Stop, Hide
So essentially – you can have interactive content that’s not accessible, as long as it’s duplicated elsewhere in the email AND as long as your inaccessible content meets these bare minimum requirements.
In email, we’re not generally worried about audio control – but def check that one out if you have audio content in your email. (This does still apply to videos auto-playing with audio!) It’s also pretty rare that we have animated gifs cross our desks that violate the Three Flashes criterion too – again though, if you have a flashy gif or animation, please look into it.
But when we’re talking about interactive content in email I’ve seen the other two issues come up a few times. There’s plenty of carousels, for example, that autoplay but cannot be paused, stopped, or hidden by the user – which violates 2.3.1. I’ve also encountered a few hotspots and drop downs that can get you into a keyboard trap. It’s not super common and is sometimes caused by a developer error, but definitely a higher level of scrutiny is needed to avoid violating 2.1.2.
Meeting these criteria are not the same as making the interactive content accessible – just to be super clear – the only thing we’re doing here is not totally messing someone up in their attempts to get to the duplication of that content to meet Requirement 4.
So – if you meet Conformance Requirements 4 and 5 with interactive content in your email, you can make that work. But I cannot stress this enough – this is not an accessible solution.
Repeat: Meeting Conformance Requirements 4 and 5 does not mean it’s accessible. (and you MUST meet both!!)
This is more of a “lean-to tent in a dire survival situation” than a well built home. No one wants this, it’s not a solution, it’s the bare minimum that you can do with limited technology without causing real harm to users with disabilities.
It’s not equitable. It’s not a solution. It’s literally what every single email with inaccessible interactive content should have as a bare minimum. But it’s not accessible and cannot be called as such.
A solution that folks like to suggest here is to have a view in browser link that links to an accessible solution, and this feels like it should meet the above criteria… BUT – and this is such a big but here – when you do this you are adding to your plate significantly. Conceptually – the idea of separate but equal content seems like a win/win, but there’s a reason we have anti-segregation laws in the US – it’s because separate but equal rarely works out. The first big issue is that you couldn’t just have a normal view in browser link because an inaccessible interactive email is also inaccessible in a browser. You have more options to build it out though, but that essentially means you’re creating two different interactive versions of the email – and they both must have the same content and functionality. But sure, that is a thing you can do. The real issue here is going to be in keeping it updated through all of the various change rounds. If the content is not the same – it is not an equitable solution and that’s an accessibility failure. This actually has a name in the accessibility world: Conforming Alternate version and it is more complicated than you want it to be. There are rules about how that alternate version needs to be reached and some others – generally the best course of action is to lead with the accessible version, which means you’re sending folks the fallback with a link to the interactive version in a browser. Not a great experience and full of potential problems – I highly recommend reading all through that conformance doc before heading down this road!
And – again – you’re still not making an accessible interactive email, so we are still not solving the problem.
So – this is the end of Part 1 on my Interactive/Kinetic Email series. This first one might feel a bit like a softball since we’re not really even talking about interactive emails yet but I can’t begin to tell you how many people have asked variations of this question before and I really do think it helps set the foundation for what we’ll spend the next few weeks digging into.
If you feel like I’ve missed a key part of conformance I’d love to hear from you, feel free to drop some notes on my linkedin about it, please.
Next week we’re going to get into some of the construction problems we have with trying to create accessible content and I’m stoked to share that with you too!