Basics:

Aria-label or Alt?

 Look, I’m a semantic traditionalist – a title I just made up for myself – which means I will rigidly adhere to the semantic solution for as much and as long as possible. So when I first heard about folks using an aria-label in place of or in addition the alt attribute, I was pretty confused. Why would you do that? Well, I did some light testing and found a few interesting details. 

As always in email accessibility, this gets complicated and goes into a broader topic that I won’t get too into here but will have another multi-part series to cover it in more detail. That topic is – what is our responsibility to manage? And it’s a bit of a doozy for us email marketers used to controlling for every single email client’s crazy rendering.

If you missed my primer on ARIA in general, it’s probably worth starting there.

Uh, okay, what is an aria-label?

An aria-label is an ARIA attribute that supports assistive technologies by helping to name elements on a page or application. Many elements in our emails need an “accessible name,” which is a way for AT to define the element to AT users. Most of these are provided by semantics: The accessible name of an image is its alt text. The accessible name of a link is its link text or its image’s alt text. In the web world, you usually see aria-labels when labeling interactive elements so that AT users can better understand how they should interact with those elements on a page.

A fairly easy example would be the “X” icon used to close a pop-up window (thinking of email hotspots here as we’re not using native UI on that window). As a sighted user, I see an “X” and know that it means close, but if that is a character entity or image, an AT user would not immediately know that the same way without us telling them what it is. Providing an aria-label of “close” would help users better understand the functionality of that interactive element and how they need to interact with it. (This is literally using an aria-label when a visible label cannot be used)

An aria-label can also describe something generic to make it more specific and easier to understand for AT users. Example: If you have two different navigation landmarks, you could use an aria-label attribute to name them differently like “primary” and “secondary.” Well, you’d really use the aria-labelledby attribute for this. It’s one of many ARIA attributes that serve different functions, and aria-label is really more focused on interactive elements. 

However, we work in email, a special snowflake of rabbit holes, and shoddy support. And guess what? Aria-labelledby has really bad support – like most ARIA attributes in email. I won’t go too far down this particular rabbit hole, but the consensus is that if you need to name something for AT in an email, you need to use aria-label. 

So this is where we kinda take a bit of a left turn from web accessibility. Don’t take that as a blank check, there are still things you need to know!

Reminder: Rule #1 of ARIA is don’t use ARIA!

(Just putting this in here again so you don’t forget!)

If you’ve ever had to dive into a CSS ocean of !importants you know that our code has a specific hierarchy and that there are ways to override that existing hierarchy. In the world of accessible names, there is a specific hierarchy: 

Aria-label > Semantic element

If you have an aria-label and an alt attribute in your image, the aria-label should be read and not the alt attribute. (Well, when aria-label is supported anyways)

So if you have an image of a cat and you give it an appropriate alt value like “cute cat napping on me as I write my post,” but there’s also an aria-label value that says “stinky cheese,” an AT user is going to get a completely different idea of the content of that image. They will not understand why you have a photo of stinky cheese when the rest of your content is about your sleepy cat. This sloppy coding also happens with alt text all the time, so I’m pointing out the exponential risk of sloppiness.

Look, if you have absolute control of the start to finish of an email, you can load an image up with alt attributes and aria-labels if you want, I guess, but we work in an incredibly fast and efficient industry. If you get hit by a bus and the guy they pull in to replace you doesn’t know to change that aria-label, you create a real mess for AT users. Let’s be real, if we all got hit by a bus, it’s unlikely the person filling our boots will mess with the alt attribute either.

But honestly, if you already have alt attribute in your image, why would you repeat yourself with an aria-label? 

There are plenty of times in email development where we have to code redundant things. If you still use VML buttons, sometimes you’re essentially building an outlook button and an “everything else” button, so two links. (Also, please stop using VML) But if you’ve been in this industry long enough, you know that things commonly go wrong. Last-minute changes make for hasty fixes and things get skipped. Or a project gets handed off without great documentation and a part of the process gets skipped. That’s probably my biggest issue with having the image text alternative in so many places: the risk of incorrect alternative text. 

Incorrect text alternatives are actually worse than no text alternatives.

But I also hate redundant code and try to purge it whenever I can, so this causes some conflict for me. Also, aren’t we trying to reduce the amount of code we’re using to create a more sustainable universe a la Alice Li’s Litmus Live keynote??

Remember the beginning of this post when I said I did some testing? I may have gone just a bit overboard… I ended up testing 15 images, some linked, some not, and with a wide variety of combinations of an image with an alt attribute, an image with an aria-label, and a linked image with an aria-label on the link. Basically, I tested every combination I could think of.

I hoped to find the best solution to share it with you. Surprise! We work in email and there’s never just one solution!

In the large majority of email clients and screen reader combinations that I tested, the overrides work as I detailed above. The image alt attribute works fine on its own, but if you add an aria-label to the image, the aria-label is read instead. Additionally, if you apply an aria-label to the link wrapping the image, that aria-label is read instead. 

However, there are still many email client and screen reader combinations that don’t support aria-label. I was also surprised to discover that some of those combos support the aria-label on the image but not on the a tag. There were a few other weird nuggets: Voiceover on a Mac using Outlook does some weird stuff: if an image is linked, it won’t read the alt attribute or the aria-label on the image, but it will read an aria-label on the a tag. (It’s the only email client that did this in my testing.) Outlook 2021 on a PC doesn’t use the aria-label on the a tag at all but will use the aria-label on the img tag. Outlook 365 on a PC won’t use any of the aria-labels, unless you’re using JAWs, in which case you’ll be able to hear the aria-label on the img tag. But every single image and linked image worked with the alt attribute only, except for that wild Outlook on a Mac scenario, which I’ll talk about in a minute.

It’s worth noting that the aria-labels on the image or the link do not cause any problems when ignored by screen readers. There are no rendering issues associated with them; they just aren’t read if they’re not supported. 

You can take a look at my test results here.

So, what does all of that mean for email marketers?

Well for me, it means use that alt attribute and use it right. Don’t complicate things by adding aria-labels, the support is super wonky and not really worth the trouble. You’re adding additional work for yourself to put the same alternative text in multiple places and I just don’t see a benefit in doing it that way.

I vacillated quite a bit about the Outlook on a Mac situation. On the one hand, you can absolutely put an aria-label on the a tag that matches the alt attribute on the img tag and be confident that you’re making that experience better for those with a screen reader, so long as you update both places. However, this goes into a broader discussion about who is responsible for accessible emails – is it the email developers or the user agent (email client)? For this, it is pretty clearly an Outlook bug that needs fixing. If you’d like to test this yourself and report it to Outlook, that would be rad. Here are the instructions for reporting a problem. Although these instructions just open a chatbot, if you choose the option under “Contact Support” called “Feedback,” you can then “Report a Problem.” I’ve already reported the issue myself, and I hope that if more of us report it, we’ll be in a better place to enact change and keep us from chasing after yet another chunk of redundant code. Of course, while we wait for changes, you can definitely still use aria-label on the a tag, but please only do this if you’re able to fully control changes and updates to this attribute! Or better yet, just stop linking all the images! That’s better for everyone as reducing linked images reduces accidental clicks.

What should we avoid?

Definitely don’t use the aria-label as a way to add information to your alternative text. As illustrated above, it really doesn’t work that way. There was only one instance in my testing where the aria-label *and* alt attribute were read, and that was gmail.com on a PC using Narrator. (WHY???) Which is again, a failure from the email client as it’s presenting content incorrectly.

One more honorable mention: In the email geek accessibility channel, Matthieu Solente pointed out that the WCAG mentions other ways to fill the text alternative requirement. Largely, that is for the title, figcaption, or caption attributes. And once again, we get into the special snowflake of email development – we just don’t know how well those work. (Though it looks like we have a pretty good idea) And because we can’t know for sure if they’ll work everywhere, it’s best to stick with the alt attribute because we already know how well it works.

Fun note: One of your takeaways here should be, “Wow, it’s wild that there is so much variation with these different email clients and screen readers!” because, yeah, wow, it’s a real mess out there. That’s why we’re figuring this stuff out!

Well, there you have it. Did you think this was that complex when you started reading? I am a firm believer that knowing better helps you do better, so get out there and make your emails more accessible!