Accessibility Report 2024

Last modified: 3 July 2024

This is our third accessibility report. We have spent the last year collecting emails as part of our data collection project and have analyzed more than 100,000 emails than we did one year ago. Since the last report, we’ve collected 409,663 emails to be included in this years accessibility report.

Out of that number, 306 could not be analyzed, bringing the total of emails analyzed down to 409,357. Only 28 emails contained no issues, representing two brands.

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 2023 and May 2024. We collected 409,663 emails from multiple industries in multiple languages. We do attempt to diversify our data set as much as possible. Around 69% of the tested emails are in the English language, and according to Statista 52.1%, of the content on the internet is English language. This result does conclude that our data set is more heavily weighted to the English language.

The emails comprised 7,868 unique from addresses, sent by 2362 unique domains.

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 the 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.

What’s changed since 2023

The Parcel team are constantly looking for ways to improve the accessibility testing tool. Last year’s report helped flag up a few edge cases that we could then improve. It also encouraged more user feedback and suggestions, so a few changes were made.

• Blank content doesn’t require language and direction. Some emails were getting falsely flagged for things that don’t require a language setting. The most common occurrence was when a tracking pixel was added. These settings aren’t required as long as this image has an empty alt attribute.
• More accurate detection of data tables. Some correctly formatted data tables were incorrectly flagged to say they needed role="presentation". This logic has been refined to detect data tables and exclude them from this rule.
• More accurate detection of lang and dir settings. A small number of emails that were passing tests but were found to be missing top-level direction settings. This logic has been updated to catch these.
• Color contrast checking was added. This was the most commonly requested feature so it was added and now emails are checked for color contrast in both light mode and dark mode.

In response to last year’s report, Parcel released an accessibility transformer, which can be applied to an email to solve ~80% of the flagged top issues. We were hoping that with the release of an automated solution, we’d see a shift towards more emails passing the checker.

Results

Issues severity

Accessibility issues are categorized into four 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 28 (0.01%) passed without issue. And those emails came from two brands.

• Houston Chronicle
• Parcel.io

Email that pass our checks may still have accessibility issues that we cannot pick up through automated testing. For example, we check if an alt attribute is present on an image, but we do not check 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 be unnecessary if the message is short.

Top 10 most common accessibility issues in email

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

Issue present in 99.17% (406000) of emails tested.

Number of appearances: 1471145.

Why it’s needed:

The direction of the language set in the email client will 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.

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

Issue present in 98.29% (402,382) of emails tested.

Number of appearances: 1,463,270.

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.

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

Issue present in 88.97% (364,240) of emails tested.

Number of appearances: 16,417,428.

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.

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

Issue present in 79.23% (324,337) of emails tested.

Number of appearances: 324,337.

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: Links must have discernible text

Issue present in 73.73% (301,825) of emails tested.

Number of appearances: 3016075.

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. Alternatively you could add visibly hidden text inside the <a>, this is text that is styled to be hidden from the screen but still remains in the DOM. There is also an option to use an aria-label or a title attribute on the <a> however these have limited support in email.

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

Issue present in 68.32% (279,706) of emails tested.

Number of appearances: 279,706.

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.

(7) Critical: Images must have alternate text

Issue present in 57.89% (236,993) of emails tested.

Number of appearances: 2,535,736.

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 34.95% (143,094) of emails tested.

Number of appearances: 143,094.

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.92% (69,272) of emails tested.

Number of appearances: 102,704.

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) Serious: Links must be distinguishable without relying on color

Issue present in 16.91% (69,253) of emails tested.

Number of appearances: 277,536.

Why it’s needed:

Some people with low vision or color blindness may struggle to distinguish links from surrounding text when the design of the links doesn’t stand out.

How to fix this:

Make sure links have something other than colour to make them stand out. The default link style of text-decoration: underline is the easiest and probably the best solution. If you must only relying on color then you need to reach a contrast ration of 3:1 compared to surrounding text, however this can be a tricky balance to achieve while still maintaining sufficient contrast against the background.

Comparing to the rule set from last year

As a number of the changes to the rules are down to fine tuning of the code it’s hard to undo these. However we can remove the color contrast rules and look at how that would have changed things.

Running the report without the color contrast rules, the total number fo emails with critical or serious issues comes down to 99.95%. And total number of emails passing without issue is up to 40. We no longer see the “Links must be distinguishable without relying on color” issue in the top 10, as that partially uses color contrast in it’s calculation. Instead we see the reurn of “VML must have alternate text”.

Conclusions

Although we have seen a few changes from last year, with new rules in place and some movement in the top 10 issues the overall outcome is the same. 99.97% of email are failing accessibility checks. Because the rules have become more strict achieving the same result can be seen as a small win, but we still have a long long way to go.

Issues related to VML have fallen off the top ten list, and in its place one of the new color contrast rules Links must be distinguishable without relying on color.

We also saw the order of the issues presented change. Missing lang attribute from the <html> tag has seen the most significant change, dropping from 72.19% down to 68.32% which is promising, however we are still seeing 98.29% of email not setting a language inside the body. So although this issue will be fixed for some emails clients, it will still be very present in a lot of others.

Four of the top 10 issues are completely fixable by any marketer, regardless of the tooling involved. Images should have alt text, emails should contain an H1, links should be distinguishable without relying on color (ie. include an underline), and link text should be descriptive. Each of these issues should be something a marketer can access from either a drag-and-drop editor or a code editor.

Something like Parcel’s accessibility transformer can handle five other issues out of the top 10, such as ensuring that text direction is specific and language is defined.

As this project has collected over 700k emails over a two-and-a-half-year span, we still see emails presenting the same issues. We encourage tools to continue to surface critical and serious issue that the marketer can fix, and enable easy adoption of fixes such as defining text direction, or setting language.

Are you curious about what issues you are facing? We recommend downloading your email file (either as HTML or an EML file) and uploading it to Parcel to run the accessibility checker and identify where you might be landing.