How to Conform to WCAG (Web Content Accessibility Guidelines) in Email

WCAG (the Web Content Accessibility Guidelines) make the web a more accessible place for everyone. They’re written for web content, not email content, but as the two have a lot in common, conforming to WCAG lays a good foundation for applying accessibility to email.

How do you conform to WCAG when developing email? In this tutorial, I’ll show you how!

There are several versions of WCAG. The current version is WCAG 2.1, and it’s referred to as a ‘recommendation’. The next version will be WCAG 2.2, and this is currently referred to as a ‘working draft’. It’s due to become a recommendation soon.

While the World Wide Web Consortium (W3C), the creators of WCAG, encourage the use of WCAG 2.2, most conform to WCAG 2.1. Indeed, WCAG 2.1 is the version that public sector websites and mobile apps in the UK must conform to by law.

According to the W3C:

There are three levels of WCAG conformance: A, AA, and AAA.

A is the lowest level of conformance, and AAA is the highest level of conformance. AA is the level that’s conformed to the most. Indeed, AA is the level that public sector websites and mobile apps in the UK must conform to by law. If you claim to conform to AA, you must conform to A as well. It’s rare to see AAA conformed to in full.

Each guideline’s Success Criterion has been assigned a conformance level by the W3C (A, AA, or AAA), which helps you identify which Success Criterion your email content needs to meet. For example, if you’ve chosen level A, your email content needs to meet all the relevant guidelines with a level A Success Criterion. If you’ve chosen level AA, your email content needs to meet all the relevant guidelines with a level A and a level AA Success Criterion. If you’ve chosen level AAA, your email content needs to meet all the relevant guidelines with a level A, a level AA, and a level AAA Success Criterion.

The W3C explains that:

To understand what the W3C’s explanation means, it’s helpful to look at an example of a Success Criterion. So let’s look at Success Criterion 3.1.1 Language of Page:

(Level A)

The default human language of each Web page can be programmatically determined.

As you can see, Success Criterion 3.1.1 Language of Page states its:

You’ll note that there are two links: Understanding Language of Page and How to Meet Language of Page. These ‘Understanding’ and ‘How to Meet’ links accompany each Success Criterion and link to two useful documents to help you understand and meet each one.

Work through your email and meet the Success Criterion for each piece of content within it, reading the ‘Understanding’ and ‘How to Meet’ documents to help you. The guidelines have been broken down into four sections to help you identify which Success Criterion relates to which piece of content within your email. WCAG calls these sections ‘Principles’, and the ‘Principles’ are ‘Perceivable’, ‘Operable’, ‘Understandable’, and ‘Robust’, also known as POUR:

Let’s look at each principle and the content their guidelines apply to in a little more detail.

There are four guidelines within ‘Perceivable’, all with their own ‘sub-guidelines’. They are ‘Text Alternatives’, ‘Time-based Media’, ‘Adaptable’, and ‘Distinguishable’. The types of email content they apply to, in the order they appear, include:

There are five guidelines within ‘Operable’, all with their own ‘sub-guidelines’. They are ‘Keyboard Accessible’, ‘Enough Time’, ‘Seizures and Physical Reactions’, ‘Navigable’, and ‘Input Modalities’. The types of email content they apply to, in the order they appear, include:

Note: the copy (words) often get overlooked, but the W3C also provides some useful tips for writing for accessibility.

There are three guidelines within ‘Understandable’, all with their own ‘sub-guidelines’. They are ‘Readable’, ‘Predictable’, and ‘Input Assistance’. The types of email content they apply to, in the order they appear, include:

There is one guideline – ‘Compatible’ – within ‘Robust’, with its own ‘sub-guidelines’.

Within the ‘How to Meet’ documents that accompany each Success Criterion are listed the techniques that can be used to meet them. Not all the techniques need to be used—only the ones relevant to the content and relevant to email.

The techniques relevant to email are ‘General’, ‘ARIA’, ‘HTML’, ‘CSS’, and ‘Failure’. The techniques not relevant to email are ‘Flash’, ‘PDF’, and ‘Silverlight’. In the documents, the techniques are prefixed with the appropriate technique type, making it easy to identify each one:

To understand how the prefixes are applied, it’s helpful to look at a ‘How to Meet’ document. So let’s look at Success Criterion 1.1.1 Non-text Content:

You can meet this Success Criterion using General, ARIA, Flash, HTML, PDF, and Silverlight techniques, indicated by their prefixes. Of these, General, ARIA, and HTML are relevant to email.

Some techniques sit under situations to help you determine the appropriate technique for your content.

The techniques for Success Criterion 1.1.1 Non-text Content sit under six situations, labelled A to F. The first situation in this example is ‘Situation A: If a short description can serve the same purpose and present the same information as the non-text content’, and its email-relevant techniques are as follows:

The other techniques that sit under Situation A, such as Flash and Silverlight, have no relevance to email.

There are several tools that will help you test your email’s accessibility. Let’s look at a few of them:

The ‘WAVE Web Accessibility Evaluation Tool’ provides snapshots of web page accessibility, and it can be used to provide snapshots of email accessibility too. Simply insert the email’s ‘View in browser’ URL into the ‘Web page address’ field.

The tool features five tabs: ‘Summary’ – ‘Details’ – ‘Reference’ – ‘Structure’ – ‘Contrast’. Each tab contains a report on its accessibility.

A brief report. It presents the number of ‘Errors’, ‘Alerts’, ‘Structural Elements’, ‘Contrast Errors’, ‘Features’, and the use of ARIA.

A detailed report. It presents the number of ‘Errors’, ‘Alerts’, ‘Structural Elements’, ‘Contrast Errors’, ‘Features’, and the use of ARIA, listing each one. Accompanying each one is a useful information icon, which, when selected, opens up a ‘Reference’ tab, providing contextual information about that specific piece of content, including references to WCAG.

Presents valuable information about the item that you selected within the ‘Details’ tab. It explains ‘What it Means’, ‘Why it Matters’, ‘What to Do’, ‘The Algorithm… in English’, and ‘Standards and Guidelines’. The latter cross-references its own ‘WCAG 2 Checklist’.

Presents any HTML sectioning elements (e.g. <main>, <nav>, <aside>, <header>, <footer>) and heading hierarchy. If there isn’t a structure (as I’ve found on multiple emails I’ve looked at), it simply states, ‘This page has no heading structure!’

Presents color contrast failures it identifies, measured against WCAG 2.1 A and WCAG 2.1 AAA. The sliders within this tab allow you to adjust the colors to ones that pass, which you can then apply to your CSS.

Finally, you can switch styles on and off to understand whether the content follows a meaningful sequence as per Success Criterion 1.3.2 Meaningful Sequence.

The WebAIM Contrast Checker is the same tool as the one ‘built in’ to the ‘WAVE Web Accessibility Evaluation Tool’, except that you have to insert the hexadecimal color codes manually.

Built by Maarten Lierop and Jordie van Rijn, this email accessibility evaluation tool allows you to validate an email before it’s sent, by inserting its HTML, and after it’s sent, by inserting its ‘View in browser’ URL. Like the WAVE Web Accessibility Evaluation Tool, it presents a valuable report.

As you’ve seen, conforming to WCAG in email requires effort. However, if you follow the process I’ve outlined in this tutorial, you’ll achieve it with minimal effort. I’ll leave you with a summary of that process:

Get off to a solid start in your next email project by using a professionally designed email template from Envato Elements.