The W3 Consortium maintains a list Web Content Accessibility Guidelines. Similar to the web and print communication requirements of the US Rehabilitation Act section 508, these these are broad goals for any piece of outbound or inbound communication.
But, if your content isn’t directed at folks with known disabilities, are these guidelines actually important? Yes, and for more reasons than you might think.
I wrote a post about accessibility audits in general, and why they are such a critical part of any content or business strategy. In this quick rundown, I’ll describe how I audited a common email template used for outbound marketing, bringing it fully into WCAG AA compliance (or better), and how that is supporting new AI inbox features.
Back-end: What the inbox sees
The first reader of any email is the inbox or email client, so that’s where I begin.
- The <head> section includes fully realized but minimal CSS to reduce send size. Rather than account for as many potential variations as content creators may possibly want, the template is designed with a limited set of elements arranged in a variety of pattern options.
- The preheader text is written as a complete summary of the email’s main content and primary CTA, as these tokens are processed first by AI inbox tools. Preheaders are also visible in the email body on some clients, which makes this summary statement more useful for those audiences.
- A complete directory of images, alt text, and short-URLs is maintained in Sharepoint, where email content is drafted and approved. This allows us to test specific constructions of items that most users do not see (but AI inboxes do) and update them globally.
Middle-end: What the content creator sees
At the time of writing, I am the only person creating and sending emails, but I know that won’t always be the case. So, I made the template into the instructions.
Every editable space has a description of what should go in it. Every larger body section has an instructional banner above it. During email creation, all non-necessary components are deleted first, then necessary components are filled in.
As a result, we maintain accessibility compliance by pre-designing and pre-approving all major email patterns. Colors, image sizes, and content elements have all been designed for best results across devices, email clients, browsers, screen sizes, and accessibility concerns.
We are also able to experiment with different approaches to AI inboxes more easily. Email management services do not provide information about AI tool handling of email content (i.e. we know that X% of emails were opened, but we don’t know what breakdown of that percentage was clicked to open, what was pre-fetched by a client, and what was opened by an AI agent to create an inbox summary), but we can compare historical data for click, open, and read rates in this template for email clients that are known to have significant AI components, like the Gemini inbox in Gmail.
Front-end: What the audience sees
The end result isn’t necessarily flashy or exciting (it can be, but that’s not the brand voice here). Instead, the end result is accessible: it’s easy to read on any device and under more constraints that regular readers may be experiencing. This is a b2b or b2specialist approach, where the audience is looking first for technical details about a system, solution, or article. In extensive testing with these audiences, visual flair does not move the needle as much as an email design that provides 1-2 core technical points that can be identified above the fold on the landing page.
