Alert:

Interactive Emails and Accessibility – Part 2

Last week, in part 1, we talked a bit about the general expectation that interactive/kinetic emails can’t be accessible – along with our first problem that we have with our quest for accessible content: Conformance. This week we’re getting into the specific experiences that interactive elements create for assistive technology users and some of the ways we can get around them.

Problem #2: Keyboard Access

Alright so now we’re getting into the actual interactive content itself and talking about why it can’t be accessible and SC 2.1.1: Keyboard is a big stopping point for nearly every interactive element. This is a Level A conformance level – meaning that it is one of the baseline requirements for calling your content accessible.

Keyboard access is met when “All functionality of the content is operable through a keyboard interface” – said a different way it means that anything you can do with a mouse must be able to be done with a keyboard.

For those of you that might be new to this concept – screen reader users generally use their keyboard to navigate digital content. However – keyboard access has a much broader use case. Folks with different mobility issues may use modified keyboards or specific hardware that works similarly to a keyboard. Other people, like me, just like navigating with a keyboard because in many ways it’s much easier than using a mouse. 

Keyboard users can use specific keys to access different parts of the content and when we’re talking about interactive emails we’re asking the question “can everything in this interactive element be done using only a keyboard?” and the answer very often is no. Our goal here is to be able to navigate to the interactive elements and activate them using only a keyboard.

I don’t want to derail myself too far here, but if you’re wanting to test these situations you’re going to want a bit of a primer on how to use screen readers. Deque has this amazing collection of guides for screen readers that is incredibly helpful. However, since we’re talking about interactive elements, we’re really limiting our use case to email clients (and devices) that support these components which makes things ever so slightly easier. Please note that apple’s keyboard accessibility is tricky and works differently than standard keyboard navigation, even differently than how voiceover works on an iphone.

It’s worth noting that every interactive element has a part of the content that cannot be accessed via a keyboard:

Carousel: You can’t get to the left/right buttons. If you do some fancy keyboarding, you can, but then you can’t get to the slides in the carousel. Does not meet this criteria.

Drop down menu: Go ahead and try to activate that menu button and then navigate through those links with a keyboard, I dare ya!  Does not meet this criteria.

Switch: Can you get to the switch and activate it? Nope!  Does not meet this criteria.

Hotspot: You can get into that popup, but how do you get out? Not through that close icon, that’s for sure! Again, does not meet this criteria. (Sidenote, if your focus hops out of that dialog box before you close that’s a violation of SC 2.4.3: Focus Order so you have to solve that too!)

(There’s a lot of variation in these components per creator, but you’ll still find that there’s major keyboard access issues in all the available components)

This is generally a pretty easy one to resolve – you can add a tabindex=”0” to the element so it can be focusable. (DO NOT use any value other than 0 here!) Usually that will mean that if you tab to it you can then activate it, usually by hitting the return key or space bar. This is the expected functionality – congratulations you solved another problem!

This does limit the number of kinetic elements you can use – your carousel with left/right buttons is just totally out at this point. But you can meet this criteria in most of the others, so let’s move on to our next stopping point.

Problem #3: Info and Relationships

Now that you can access that tabbed content, it needs an accessible name so the assistive technology can tell the user what this item does when you activate it, or what it is. Literally what the connection between this weird item we can navigate to and the content around it. We’re talking about SC 1.3.1: Info and Relationships (Level A)

In the Trusted Tester class, we use a tool called ANDI to test content in ways that don’t require you to be an Assistive Technology super user. It gives you a visual bar at the top of your browser page that will visually show you how your content is connected together.

Example: In this screenshot you are able to visually see that the text input field for the “Name” value is programmatically linked with a label (in green) and that it is required (in pink) and so the output tells the user that this is a name field and that it is required.

The ANDI tool is great, but a word of warning: you really do need the Trusted Tester class to fully understand the tool and use it effectively. But – it’s a good visual here so you can better understand what I mean when I say connection.

Usually in the web world, you would use an aria-label to give interactive content an accessible name. 

You remember aria-labels from our conversation last year about how I tested alt text against aria-labels for images to see which was read correctly in most situations. (Not surprisingly it’s the alt text)

So, you’d think that if the aria-label is the right choice for web interactive content, it should be supported well in email clients too, right? RIGHT?

Yea, sorry, again – email clients (and their respective assistive technologies) do not mirror web technologies. In fact, I found that in nearly every single interactive component that I tested the aria-label was a dismal failure – even on iPhones.

You know what worked? Alt text! 

Super wild – on inputs (part of the code that makes up a lot of these interactive elements) you couldn’t functionally use a sprite and have it read out by screen readers – you had to use an image with an alt attribute in order for a screen reader user to be told where they landed and the intended action needed. It feels like time traveling backwards, and it kinda is – technology that functionally works for non-disabled users in email does not work well at all for some assistive technology users so we have to step back to what does work – alt text on images. 

So that Menu icon? Needs to be an image with alt text. That close “x” in your hotspot just reads “x” the way it is in most examples. You need to turn it into an image and give it an alt text that actually describes the content like “close window”.

And another thing! Some of these interactive modules also use CSS pseudo elements like :before and :after and those have some very real accessibility impacts. 

This failure is documented here in Failure F87. I found this to be an issue in my testing of a hot spot component – the text contained in the hotspot was actually in a CSS pseudo element which meant that my screen reader tests could NOT read that content at all. Which was an even weirder experience after I ensured it was tabable, so you could activate the pop up but then couldn’t read it, lol. You have to do some snazzy (read: old school) ways of adjusting the code so that the pop up still worked but wasn’t in a pseudo element.

You also have to make sure that your alt is providing good information, so we’re less describing the image itself and talking about the functionality of the image. So not “menu” but “activate to display menu” or something along those lines.

Alright – so now you can navigate via keyboard to all of the interactive elements of your page and now we have those elements connected with labels, text and/or content so that the connection between the two is clear. Now what?

Next week we’ll get even more into the weeds into some of the weirder ways we encounter accessibility issues with our kinetic content!

———-

Note: I didn’t give you any code-specific solutions or examples here and I wanted to explain that a bit. This is one part of a deep dive I did for a client so I can’t go into as much detail as I’d like to. I’m still giving you an incredibly valuable tool to be able to determine what failure looks like so you can easily evaluate your own efforts or others. This represents years of my experience, understanding, and personal testing – just to know what is even wrong to begin with. Being able to look at all of these issues holistically is the part of the research I can share and I’m happy to share with you!