Basics:

The Accessible Digital Ecosystem

TLDR; We’re digging deep into the WCAG and how it works to guide us on our path to accessible digital content. The WCAG is quite a bit more complex than you might think and not as clear as you might hope, especially when we’re talking about our weird corner of development in email marketing.

So far in this blog, I’ve focused on pragmatic accessibility solutions to make your email marketing endeavors better able to reach the most recipients possible. That has largely meant zeroing in on specific components, common coding solutions, or email “best practices” that need extra help to be accessible. I’ve also covered some basics to better help you understand the concept of disability and the Disability Rights Movement, all of which are important foundational elements that support your endeavor towards accessible emails.

Today’s post is different. Today I want to talk a bit about some of the overarching concepts of email accessibility and how they do and do not differ from web accessibility. That’s right, I’m going to walk us into the murky waters and try to pull them apart a bit so you understand what we’re up against. This is probably going to be a bit more of an ongoing series as I continue to pick this concept up, turn it around, and dig in more.

I’m hopeful that by the end of this post you’ll have some new understandings of the totality of the digital accessibility space and the kind of weird/quirky mishmash of how email does (and doesn’t) fit into it. These are my observations thus far, and I hope that as I learn more I can more cohesively explain some of these nuances.

So I’m going to go ahead and zoom us all the way out to where email is but a tiny speck. 

At this point, you are no doubt familiar with the WCAG, or the Web Content Accessibility Guidelines. These are international guidelines that describe how digital content creators can create accessible content. It is technology agnostic, which means that it applies to all digital content, from emails to web pages to apps. That’s part of why the guidelines are pretty abstract – like they don’t say “Put alt attributes on all your images!” it says “All non-text content that is presented to the user has a text alternative that serves the equivalent purpose” because the alt attribute isn’t always the right/best/available solution across all technologies. What’s important is that there is a text alternative, not the exact mechanism for it. As long as it works and performs the correct function – that’s the important part.

However, the accessible digital ecosystem doesn’t stop at consumable digital content. It also includes the User Agent Accessibility Guidelines (UAAG) and the Authoring Tool Accessibility Guidelines (ATAG).

The UAAG is a set of guidelines that covers a user agent, which is any software that retrieves, renders, and facilitates end-user interaction with Web content, or whose user interface is implemented using Web technologies. (You can read more about user agents here.) In fact, email has its own kind of user agent called a “Mail User Agent” which we in email marketing call an email client. 

I won’t talk too much about the ATAG because it’s a bit out of our reach, but it ensures that the authoring tool you use to create the digital content is also accessible to users with disabilities. (Yes, this does mean that the WYSIWYG drag-and-drop email creators should be accessible. Sorry/not-sorry to literally everyone that owns one of those.)

Each of these different Accessibility Guidelines has an incredible amount of documentation. Like, it’s a lot a lot. 

The WCAG has four principles: perceivable, operable, understandable, and robust. The UAAG shares three of those principles: perceivable, operable, and understandable and adds Programmatic Access and Specifications & Conventions.  Each principle is broken down into guidelines, which are, in turn, broken down by conformance level: A, AA, or AAA.  Each of those success criteria has its own supporting documentation. That documentation is broken down even more, with an “Understanding document” that gives a broad overview of the success criteria and how it impacts users with disabilities and several “Techniques documents” that list out a whole lot of specific issues, solutions, or failures related directly to that success criteria. 

Yipes! I think we all want to imagine the WCAG as a simple and easy to follow list of guidelines, but it really is a whole lot more than that. 

Example:

In the WCAG, under the principle of “Perceivable,” there is a guideline of “Distinguishable.” Under that guideline, there is a Success Criterion “SC 1.4.3: Contrast (Minimum) (Level AA)” which has 9 technique documents supporting different usages, techniques, and expected failures. 

WCAG > Perceivable > Distinguishable > SC 1.4.3: Contrast (Minimum) (Level AA) > Understanding document > Technique Documents (6 sufficient techniques, 1 advisory techniques and 2 failures)

And that’s just for color contrast, which is a fairly simple and straightforward criterion.

Then you move to more complex success criteria, where you end up doing a bit more digging into the WCAG documentation to find a solution that will actually work in your situation. If you were creating a web page, most of the standard solutions would be pretty easy to implement, but because we work in email – we have to dig quite a bit deeper.

Example: In my notes about animated gifs, I talk about how we can’t really meet the criteria for Pause Stop Hide (SC 2.2.2) because we can’t control whether or not the animated gif can start or stop from our code alone. So after some digging, we find a technique document that spells out our exact scenario and how to meet that criteria differently.

In most situations, you will find technique documentation that will give you a way to meet that Success Criteria in your emails.

Wait, there’s more!

In addition to all of that, the success criteria for the UAAG and the WCAG work together to make sure that the accessible content we put into our HTML files can be read appropriately by the recipient using their user agent.

Example: In the WCAG, we have SC 1.1.1: Non-text Content (Level A) which says “All non-text content that is presented to the user has a text alternative that serves the equivalent purpose” and in the UAAG we have 1.1.1 Render Alternative Content which says “The user can choose to render any type of recognized alternative content that is present for a content element.” So, a little simpler, we are saying “Hey dummies, put something like alt text on your images and then you other dummies, make sure users can read it!”

One of the bigger differences between web and email accessibility:

When I talk to more general accessibility folks and start talking to them about how little support there is for certain accessible content in email, they basically say “Submit a report to the MUA and move on with your life”. 

That’s right, my fellow accessibility specialists do not spend hours testing odd hacks to make sure that the digital content is accessible in various user agents. They *rightfully* acknowledge that the error is on the side of the user agent, and not with their totally accessible code, and place the responsibility squarely on the shoulders of those user agents.

(pause for dramatic effect as you try to square this against the entire history of email development as you know it)

I think back to the first time I had to make something render in Lotus Notes and what a hot mess that was. What if we had all just collectively said, “Yeah no, this is a Lotus Notes problem and not my problem to solve”? Hahahahahahahahahahaha, our entire industry would have collapsed and my life would probably be super different than it is today. (I kid, sorta)

So when I first heard this I was a little confused, but within the context of web standardization, it really does make sense. Web browsers have detailed documentation describing what new coding solutions are supported on which versions of those browsers. It is super easy (well, compared to email) to use the correct solutions outlined by the WCAG and other best practices.

So I explained to my non-email accessibility folks that in email, we don’t have any tangible standardization. (Cry a little tear to the now defunct Email Standards Project) I also explained that it is absolutely common for us to format content in a few different ways to ensure that it works across many different email clients. They equally looked at me like I was an absolute crazy person.

And this is kinda where we get into a bit of a gray area. 

I talked about this gray area a bit before when I shared my notes on alt text vs aria-label, where Outlook on a Mac wasn’t reading the text alternative and how that caused a problem for Voiceover users.

If we go the way of standard accessibility folks, we’d have to wait on email clients to get off their duff and fix their UAAG failures. But we know from experience that email clients are not super keen on standardizing their processing of our HTML files and may not get this done anytime soon. Maybe accessibility failures would be more motivating? Hard to know.

But if we look at this like historic email developers, we are going to be forever chasing down these fires and then retesting them with every email client update. 

😱

(And I haven’t even started to explain how different combinations of screen readers and email clients frequently pick and choose what components to read!!)

💀💀💀

So here are some remaining questions I have after sitting on this for a bit:

1. To what extent do I need to craft my emails to meet every mail user agent’s quirky support of accessible best practices? Does my responsibility to the greater email community include describing hacks to get something to work no matter what? And then constantly staying on top of that every time something changes? (Do I even have time for that?)
   
2. To what extent do I need to catalog and test UAAG failures and what misses should be prioritized? Will email clients even care if we start reporting these issues? What external reasons could these mail user agents have for not supporting these accessible solutions?
   

I’m guessing as you’ve read this you’ve found yourself pulled in one of two directions: you either want to push for more standardization of mail user agent accessibility support, or you want to push for making more here-and-now changes to your code to support all users immediately.

I personally find myself somewhere in the middle, and to be honest, I’m still feeling it out a bit. 

I think that some situations are so bad and reasonably universal that they’re worth adjusting on our end.These situations would include: not using the aria-labeledby attribute; not using VML; and using tables for layout and adding either the role presentation or none to those tables.

I think that other solutions that can get unwieldy or are fixes for just one email client are a little more questionable. Why should we spend hours of our lives fixing something that is very clearly the responsibility of the mail user agent in question? That seems a little bit more tackleable from our side.

To be quite honest, I’m not entirely sure there is a clear answer to this situation. As we go along, I expect things to get a little bit clearer. We’ll continue to bring in more accessibility folks into the mix and get some additional perspective. Maybe the folks that push the buttons at our top email clients will feel a little bit more heat about these accessibility failures and implement some solutions of their own?

Time will tell, and I’m glad we get to be a part of it. 🙂 

Note: I’m re-reading this post before sharing it and realizing that for some of you that are newer in this journey you might have a very “wth am I even doing then” response to this post. And that’s kinda fair, honestly, but I think there’s still plenty of really solid adjustments that we can and should make to make our emails more accessible. I’m definitely trying to illustrate that this isn’t as clear as it might feel to those on the outside – but there are absolutely hard truths to follow that should absolutely be done.