Accessibility Report 2023

Last modified: 18 May 2023

Although this is our second accessibility report, it is our first with a full 12 months of data. We have spent the last year collecting emails as part of our data collection project and now have nearly 10 times the number of emails we tested last year.

This report does include the 35,604 emails tested in the first report, meaning there is some repetition. We did this because in the future we intend to compare the results with past year(s) and the first report was only a couple of months worth of data. Another reason for including previously tested emails is the updated accessibility checker, so we wanted to retest these emails with those rules applied.

Result

99.97% of HTML emails tested contain accessibility issues categorized as “Serious” or “Critical”.

This report was created in collaboration with our partner, Parcel.io

The data

The data was sourced by the Email Markup Consortium Data Collection project between May 2022 and May 2023. We collected 303,847 emails from multiple industries in multiple languages. We do attempt to diversify our data set as much as possible. Around 56% of the tested emails are in the English language, which roughly matches the percentage of English content on the internet according to Statista. The emails comprised 7388 unique from addresses, sent by 2481 unique domains.

Out of the 303,847 emails in our data set, 10,279 had errors and could not be analyzed. We analyzed the remaining 293,568 emails.

If you would like to add to and help expand our dataset or find out more about it, you can read more about our data collection project.

Testing methodology

The testing is performed via Parcel accessibility checker. This is a tool built specifically for email accessibility tests. Learn more about the tests and what they cover by reading the Parcel accessibility-checker documentation.

We’d like to give huge thanks to the team at Parcel.io for all the help with collecting the data and running the tests. The accessibility checker is available on the free Community plan at Parcel, so if you want to test your emails on the same criteria that we use you can do so very easily, and add it into your regular email production workflow.

Results

Issues severity

Accessibility issues are categorized into 4 categories depending on how serious they are. These are defined by Deque Axe as:

• Mild - Considered to be a nuisance or an annoyance bug. Prioritize fixing if the fix only takes a few minutes and the developer is working on the same screen/feature at the same time, otherwise the issue should not be prioritized. Will still get in the way of compliance if not fixed. Should be very infrequent.
• Moderate - Results in some barriers for people with disabilities, but will not prevent them from accessing fundamental features or content. Prioritize fixing in this release, if there are no higher-priority issues. Will get in the way of compliance if not fixed. Should be fairly common.
• Serious - Results in serious barriers for people with disabilities, and will partially prevent them from accessing fundamental features or content. People relying on assistive technologies will experience significant frustration as a result. Issues falling under this category are major problems, and remediation should be a priority. Should be very common.
• Critical - Results in blocked content for people with disabilities, and will definitely prevent them from accessing fundamental features or content. This type of issue puts your organization at risk. Prioritize fixing as soon as possible, within the week if possible. Remediation should be a top priority. Should be infrequent.

In our test we looked to find the highest category of issue recorded in each email:

From this we can see that 99.97% of emails tested contain accessibility issues categorized as “Serious” or “Critical”. These are the highest categories and fixing these issues should be considered high priority.

Emails without issues

Out of all the emails we tested only 35 emails (0.01%) passed without issue. And those 35 emails came from 5 brands.

• Email on Acid
• Mailjet ¹
• GitHub
• Transavia
• Houston Chronicle

It is worth mentioning that emails that pass our checks may still have accessibility issues that we are unable to pick up through automated testing. For example we are checking if an alt attribute is present on an image, but we’re not checking if the text is suitable for that image.

Also some emails with mild or moderate issues may actually be very accessible as these rules often have exceptions that these emails may meet. For example a level-one heading may not be needed if the message is very short.

Top 10 most common accessibility issues in email

(1) Serious: Content inside the body should be wrapped in a lang attribute

Issue present in 96.37% (282,904) of emails tested.

Number of appearances: 282,904.

Why it’s needed:

A number of email clients will remove the language setting on the <html> element so we need to also include it on any direct children of the body element.

How to fix this:

It’s important to apply the correct language, however if you need to have a fallback for when a language is not set then you can set lang="und", this sets the language as undetermined. It’s not nearly as good as setting a language but it’s much better than setting nothing.

(2) Serious: Tables used for formatting should have the role attribute set to presentation or none

Issue present in 89.16% (261,757) of emails tested.

Number of appearances: 10,277,347.

Why it’s needed:

Table elements should only be used for displaying tables of data, they should not be used for laying out content.

How to fix this:

It’s better to avoid table layouts completely, however if you do use them you can reduce the negative accessibility impact for some email clients by setting an attribute of role="presentation" or role="none" on the <table> element.

(3) Serious: Content inside the body should be wrapped in a dir attribute

Issue present in 87.00% (255,404) of emails tested.

Number of appearances: 255,404.

Why it’s needed:

The direction of the language set in the email client will mostly inherit into the email content. So if the user has their email client set in a right to left language and they open an email written in a left to right language, this can cause several layout issues making it very hard to read.

How to fix this:

To fix this you can set a dir attribute on any direct children of the body element.

It’s important to apply the correct direction, however if you need fallback for when a direction is not set then you can set dir="auto". This is not as good as setting the correct direction but it’s much better than setting nothing.

(4) Mild: Page should contain a level-one heading

Issue present in 81.70% (239,847) of emails tested.

Number of appearances: 239,847.

Why it’s needed:

Headings are one of the main ways screen reader users navigate a document. Placing an <h1> element inside the content of the email means a user can quickly and accurately find the email content.

How to fix this:

You can add an <h1> element around the main title of your content. However not all emails require headings, sometimes email can be short and used almost like SMS with only a few lines of text. In this case a heading may not be needed, hence why this is only listed as a mild issue.

(5) Serious: <html> element must have a lang attribute

Issue present in 72.19% (211,915) of emails tested.

Number of appearances: 211,915.

Why it’s needed:

Setting a language for the document helps with a range of things from translation tools to tell assistive technology how to correctly read out the content.

How to fix this:

Add a lang="" attribute to the <html> element. It’s important to apply the correct language, however if you need fallback for when a language is not set then you can set lang="und", this sets the language as undetermined. It’s not nearly as good as setting a language but it’s much better than setting nothing.

(6) Serious: Links must have discernible text

Issue present in 71.36% (209,493) of emails tested.

Number of appearances: 1,952,631.

Why it’s needed:

Link text tells the user where the link is taking them, if there is no link text they won’t know what the link is for.

One of the main causes for this we’ve seen is linked images that don’t have alt text set. It’s ok to use an empty alt attribute for a decorative image, however if the image is linked it’s not decorative it’s functional.

How to fix this:

Add some text inside the link. If this issue is flagged on an image you can add some text alongside the image (but still inside the <a>) or you can add an alt attribute with text that describes the content of the image as well as the page it’s linked to. There is also an option to use an aria-label or a title attribute on the <a> however these may have limited support in email.

(7) Critical: Images must have alternate text

Issue present in 55.26% (162238) of emails tested.

Number of appearances: 1,753,810.

Why it’s needed:

Alternate text (or alt text) is used to describe the content of an image to people who may not be able to understand it fully just by looking at it. This could be down to a visual impairment or in the case of text in the image can also cover people with reading difficulty.

How to fix this:

An alt="" attribute is always needed, but in some cases can be left blank, when the image is purely for decoration and not adding content, meaning or function to the email.

(8) Serious: Documents must have <title> element to aid in navigation

Issue present in 35.05% (102902) of emails tested.

Number of appearances: 102,902.

Why it’s needed:

The title is shown when the email is viewed as a web page, it is also listed in some email clients. It shows in the tab allowing users to quickly see what the page is, it also gives screen reader users a quick introduction to the page.

How to fix this:

Add a <title> element to the top of your page with a short, descriptive summary of the email content. Ideally this would be descriptive of this specific email (like the subject line) but if that is complicated to include you can also use something more generic like “Email from the Email Markup Consortium”.

(9) Moderate: Link text should be descriptive

Issue present in 16.80% (49333) of emails tested.

Number of appearances: 68,676.

Why it’s needed:

Link text tells the user where the link is taking them, non-descriptive text like “click here” doesn’t give enough information to allow the user to make an informed choice to click it or not.

This becomes a larger issue for screen reader users who may be accessing the links via a shortcut key which will jump straight to the link text or via the links shortcut menu which lists all the link text of each link. Both of these cases mean there is no outside context leading into reading the link text.

How to fix this:

Write short descriptive text inside links. If you are unable to add enough detail in the visual link text, it is also possible to add visually hidden text inside a link to add more information.

It is worth noting that currently this rule is only checking for generic text in the English language, so it’s likely there are many more occurrences that have gone undetected by our tests.

(10) Critical: VML must have alternate text

Issue present in 11.33% (33,260) of emails tested.

Number of appearances: 118,887.

Why it’s needed:

Vector Markup Language (VML) is a language used for creating graphics. This means VML elements are often treated as images by assistive technology and all images require an alt attribute to add alternate text to describe the content of an image.

How to fix this:

Add an alt attribute with descriptive alternative text to the VML shape or in the case of VML groups, add the alt attribute to the outer group element. If an image is purely for decoration and not adding content, meaning or function to the email it is ok to leave the alt attribute empty, however the attribute still needs to be included.

Comparing to the rule set from last year

We ran our data set against the rule set we used for last year’s report to get an understanding of how the new rules have influenced the results.

This year 99.97% have critical or serious issues. Using last year’s rules that comes down to 99.78%

Breaking that down to look at the highest category of issue recorded in each email

• Critical 64.07% comes down to 61.05%
• Serious 35.89% goes up to 38.73%
• Moderate 0.00% goes up to 0.15%
• Mild 0.02% goes up to 0.04%
• No issues 0.01% goes up to 0.03%

Conclusions

These numbers are scarily large, 99.97% of emails are failing basic automated tests, as an industry we need to do better.

There is some good news however. When looking at the top 10 issues, the top few most common issues happen in a lot of emails, but when we look at the bottom of the list, the frequency drops dramatically. This means as an industry if we focus on those top few issues, we should be able to reduce the overall results dramatically.

A number of these issues should be quick and easy to fix and a lot of them are related so can be fixed at the same time. If every email were to declare language settings, that would remove 3 of the top 5 issues. If every email were to include alt text on images and VML, that would fix both the critical issues listed here.

We are however aware that it’s not always possible for an individual to implement the changes needed to fix these issues. There can be restrictions with various email creation and sending tools. If you are in this situation it’s important to report these bugs to the tools you are using. The more reports they receive the higher the priority of a fix becomes, they may also be able to help you with a work around to apply while waiting for the fix. No one person can fix every issue, but everyone can do something towards making some improvements.