Component:
ARIA
Every once in a while, people will bring up adding ARIA to their emails, and quite often, my response is, “NO!!” and I thought I’d go into a bit of detail to explain that.
What even is ARIA?
I like this definition of ARIA from a11y-project.com: “ARIA (Accessible Rich Internet Applications), is a specification from the W3C and created to improve accessibility of applications by providing extra information to assistive technologies, such as screen readers, via attributes which could be added to HTML.”
And ARIA truly is making the digital world more accessible bit by bit. There’s a lot we can do using ARIA to make our emails better than ever!
ARIA is somewhat like a magic wand – we can use ARIA to make an element we are forced into using because of various restraints (limitations of media, skill limitations, limitations from other external forces) and change that element to be something we *do* want to use. We can change a div into a button (but please don’t, we don’t have buttons in email), or we can change a data table into a layout table.
Okay, but let’s not get ahead of ourselves. ARIA has rules and the first one has some real Tyler Durden vibes:
The first rule of ARIA is don’t use ARIA.
This will get clearer as we go along, but we really should not use ARIA unless we absolutely have to. In most scenarios when we’re creating emails we can and should use the existing semantic structure to allow AT users to read the content in our email as expected.
We don’t need to reinvent the wheel here!
- When we create a link or CTA, that should be a typical link – an
<a>tag that wraps link text that helps the user understand where that link goes. (eww don’t even try that “click here” nonsense).
- When we add an image that we want to be linked, we wrap a link around the image, no weird background images with transparent pngs on top (WHY!?!)
- When we include a paragraph of body text, we wrap that in a paragraph tag, not an endless blob of text with random line breaks to make it visually look like separate paragraphs.
There’s rarely a good reason to use anything other than the semantic solution, and doing otherwise makes things unnecessarily complicated.
There are plenty of times when we do get to use ARIA in our emails. A good example of that would be the tables that we use for layout. Tables should only be used for data, but we take tables and extend them past their semantic use when we use them for layout in email. We use tables because other means of layout will not render appropriately and that puts us in a situation where we have to use ARIA to support our weird non-semantic coding solution. That’s why we add the role=”presentation” to our tables (you can also use role=”none”). The ARIA role here is basically overriding the semantic purpose of the table and turning it into something without semantic purpose, like a div.
So we want to use the HTML semantic elements so you don’t have to take additional steps to correct it with ARIA. We’ll talk more about this in later posts, don’t worry. The main point here is that you shouldn’t use ARIA unless you absolutely have to and when we’re talking about a lot of the content in our emails, you really shouldn’t have to.
But… this is email
I’m really sorry if I’m the first person to break this to you, but email is stupid. (Queue visual of me wanting to throw my laptop out the window a handful of Black Fridays ago)
Most of us are super familiar with this concept. We code something, it’s perfect. We send it, and some email client makes it explode. Most of us email developers secretly love this – well okay we hate to love it – but we still love it.
Most ARIA elements do not work in email. If they do functionally work in email, they still don’t really work in email the way we need them to and they definitely don’t work everywhere. Aria-labeledby is a great example of how things can go wrong.
And as much as I love caniemail.com, it’s testing doesn’t go into a lot of detail. I have found that an aria attribute can work in one situation with one screen reader and one specific email client, but that outcome can change when either of those variables changes. (I have another post coming about aria-label and just a warning, everything is wrong!)
That makes it all the more critical for us to not jump in feet-first with ARIA.
Take your time! Test all the things! Don’t let a web-focused blog lead you to do things the “right” way if you haven’t thoroughly tested that way to make sure it works with email clients and screen readers. It is not a small task, and that’s one of the many goals of this blog, to do some of this testing for you so you can go forth with some amount of confidence.
But… until they’ve been tested, and you know what you’re testing for, please try to step back from ARIA. Stick to the rivers and streets that you’re used to*.
*This is from a TLC song for you younguns. (Okay my kid just told me this is on tiktok so I guess this callout is for the older-than-me olds??)