Accessibility Report 2025

Accessibility in HTML emails remains critically under-addressed in 2025.

Across the ecosystem, accessibility failures are systemic, widespread, and largely preventable. After analyzing 443,585 emails collected over the past year, we found that 99.89% contain accessibility issues rated “Serious” or “Critical.” Only 21 emails passed all automated accessibility checks, and they came from just two brands.

This year’s report expands beyond just the code sent in HTML messages by senders. This time, we also evaluate the state of accessibility inside email clients, based on our Email Client Feature Support Rankings. Shockingly, only one email client supports all HTML and CSS accessibility features.

Result

• 99.89% of HTML emails tested contain accessibility issues categorized as “Serious” or “Critical”.
• Only 21 emails (< 0.01%) passed all accessibility checks. These emails came from a single author representing two separate brands!
• The majority of the issues are not edge cases. These are basic, machine-checkable accessibility failures.
• Only one email client supports all HTML/CSS accessibility features tested on “Can I Email?”

Partners

This report was created in collaboration with our partners, Parcel.io and Flourish

Funding

Our funding comes from our sponsors and a number of individual contributors from the email community and beyond. If you would like to support this report and help contribute to keep the EMC going, you can do so on our Open Collective page.

Summary

What’s going wrong?

The causes of the issues are systemic:

• Developers, even those experienced with web accessibility, often lack email-specific knowledge
• Drag-and-drop email builders generate inaccessible HTML markup
• Email clients fail to support key HTML/CSS features that would enable developers to build accessible HTML emails

What Needs to Change

This report is a call to action for shared responsibility:

• Senders: use tools like Parcel to audit your HTML emails.
• Template and ESP tools: audit your generated markup. Set better defaults and fallbacks. Add accessibility checks.
• Email clients: support HTML/CSS features needed to author accessible code.

A Few Leading the Way

Senders

We recognize the work of brands like Parcel and NaomiWest.ca, whose emails passed all automated tests. Their success shows what’s possible when accessibility is prioritized.

To get these same results other senders need to be putting emails through a proper accessibility QA process to check every email before it’s sent. This is pretty common when testing for rendering issues. Accessibility deserves that same level of attention.

One approach teams can take to iteratively improve the accessibility of their emails is building a robust design system that allows them to implement fixes and improvements in a single source. These changes can then roll out to all of their email templates

Email clients

We also recognize SFR Mail which supports all the accessibility features tested on “Can I Email?“. Honourable mentions to Apple Mail and Samsung Email, which are not far from the 100% mark.

Other email clients should aim to follow suit. We understand there are concerns around allowing certain HTML/CSS features that could potentially be exploited by malicious senders. If this applies to an accessibility feature, suitable work arounds or fallback options should be provided. The EMC would love to work closer with the email clients to help facilitate this.

Accessibility in HTML messages

The data

The data was sourced by the Email Markup Consortium Data Collection project between May 2024 and May 2025. We collected 443,870 emails from multiple industries in multiple languages. This is roughly 23,000 more emails than what we analyzed for the 2024 report.

• Number of emails collected between May 2024 and May 2025: 443,870
• Number of emails that could not be analyzed (due to invalid code): 285
• Number of emails analyzed: 443,585

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.

Parcel’s accessibility checker for a wide range of accessibility issues, not only looking at compatibility with assistive technologies, but also looking for issues that could affect people with a wide range of accessible needs.

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 categorised 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 organisation at risk. Prioritise 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.89% of emails tested contain accessibility issues categorised 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 21 (< 0.01%) passed without issue. And those emails came from just two brands.

• Parcel.io
• NaomiWest.ca

It is worth noting that Naomi West is on the EMC admins board, and is in charge of building both Parcel.io and NaomiWest.ca emails.

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 in the context of that message.

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 98.14% (435,326) of emails tested.

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 96.67% (428,819) of emails tested.

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 86.24% (382,566) of emails tested.

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 76.78% (340,605) of emails tested.

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 72.04% (319,550) of emails tested.

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 67.01% (297,253) of emails tested.

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) Serious: Element has insufficient color contrast

Issue present in 59.37% (263,360) of emails tested.

Why it’s needed:

Some people with low vision experience low contrast, meaning that there aren’t very many bright or dark areas. Everything tends to appear about the same brightness, which makes it hard to distinguish outlines, borders, edges, and details. Text that is too close in luminance (brightness) to the background can be hard to read.

How to fix this:

Adjust either the text color or the background-color to ensure color contrast of at least 4.5:1.

(8) Critical: Images must have alternate text

Issue present in 51.42% (228,081) of emails tested.

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.

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

Issue present in 41.35% (183,423) of emails tested.

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

(10) Moderate: Link text should be descriptive

Issue present in 17.62% (78,162) of emails tested.

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 previous years

We’ve seen a small drop in email failing accessibility tests with either Critical or Serious issues. For the last 2 years this was 99.97%, this year it’s dropped to 99.89%.

Although that change is small, we are seeing some bigger improvements in some of the top 10 issues with most issues seeing fewer occurrences than last year.

Contrast checks were introduced in the 2024 report but didn’t register in the top 10. Looking into it, there was a problem with the way the issues were grouped, although they were registering, they weren’t combining to gain significant numbers.

Industry break down

For this year’s report, we have also examined email messages sent by .edu (education) domains and .gov (government) domains. These are two sectors in which accessibility is not negotiable and should be held to a higher standard.

Education

We found 113 emails from education domains. 100% failed accessibility tests. 4% with Critical issues and 96% with Serious issues.

Only 5 emails failed with a Critical issue, and that was the same issue across all 5. Zooming and scaling must not be disabled.

The rest of the messages failed with serious issues.

100% of emails had the following serious issues:

• Content inside the body should be wrapped in a dir attribute
• Content inside the body should be wrapped in a lang attribute
• Tables used for formatting should have the role attribute set to presentation or none

Also, 100% were missing an <h1> element.

Government

We found 2556 emails from government domains. 100% failed accessibility tests. 7% with Critical issues and 93% with Serious issues. The most common Critical issue was Images must have alternate text (6.5%), we’re also seeing about 1% with Zooming and scaling must not be disabled (30 emails). As well as issues with allowed ARIA attributes (7 emails) and invalid ARIA attributes (4 emails).

For Serious issues;

• 85.6% Tables used for formatting should have the role attribute
• 83.72% Content inside the body should be wrapped in a dir attribute
• 83.72% Content inside the body should be wrapped in a lang attribute

Although it’s only a mild issue 49% of emails had Duplicate ID’s

Conclusions

This is the third full year for this report and we are disappointed to see the same issues as we have in previous years. The top 10 issues haven’t changed order since last year, apart from the addition of color contrast, which can be put down to a change in the testing and reporting.

We were hoping to see better standards across education and government emails because generally there are stricter accessibility laws for these. Although both groups have a 100% failure rate, the Critical issues are much lower than the overall stats, 4% and 7% respectively. However the sample data size for these two sectors is small: combined it’s less than 1% of total messages analyzed.

Fewer than 0.01% of emails passed automated accessibility checks. That’s a call to action. Accessibility tools exist to do better, we just need more of them to be used, and more platforms to make them standard.

On the bright side, we have seen lower percentages of issues which suggests improvements are being made. Messages with Critical issues have dropped from 66.68% in 2024 to 60.66% in 2025. This could suggest these fixes are being prioritized.

Frameworks and drag-and-drop tools are uniquely positioned to raise the accessibility baseline. Yet many still output templates that miss fundamental requirements. We know our past reports helped MJML to improve their defaults. We strongly encourage others to do the same, and perhaps start introducing automated audits on their generated code.

Accessibility in Email Clients

The data

This data comes from our Email Client Feature Support Rankings, which is based on the features tested on “Can I Email?“. The Email Markup Consortium in collaboration with Flourish, directly contribute to the “Can I Email?” project.

The following 20 HTML/CSS features have been identified as features that help developers build accessible HTML emails:

CSS features:

1. @media (hover), @media (any-hover)
2. @media (prefers-color-scheme)
3. @media (prefers-reduced-motion)
4. :active
5. :focus
6. :hover

HTML features:

1. role attribute
2. dir attribute
3. lang attribute
4. aria-label attribute
5. aria-labelledby attribute
6. aria-live attribute
7. aria-describedby attribute
8. aria-hidden attribute
9. hidden attribute
10. <hr> element
11. <img> element
12. <picture> element
13. <abbr> element
14. <code> element

These features were tested on 44 email clients:

1. Gmail (Desktop webmail)
2. Gmail (iOS)
3. Gmail (Android)
4. Gmail (Mobile webmail)
5. Outlook (Windows)
6. Outlook (Windows mail)
7. Outlook (MacOS)
8. Outlook (outlook.com)
9. Outlook (iOS)
10. Outlook (Android)
11. Yahoo! Mail (Desktop webmail)
12. Yahoo! Mail (iOS)
13. Yahoo! Mail (Android)
14. Apple Mail (MacOS)
15. Apple Mail (iOS)
16. AOL (Desktop webmail)
17. AOL (iOS)
18. AOL (Android)
19. Mozilla Thunderbird (MacOS)
20. Mozilla Thunderbird (Windows)
21. Samsung Email (Android)
22. SFR (Desktop webmail)
23. SFR (iOS)
24. SFR (Android)
25. Orange (Desktop webmail)
26. Orange (iOS)
27. Orange (Android)
28. ProtonMail (Desktop webmail)
29. ProtonMail (iOS)
30. ProtonMail (Android)
31. HEY (Desktop webmail)
32. Mail.ru (Desktop webmail)
33. Fastmail (Desktop webmail)
34. LaPoste.net (Desktop webmail)
35. T-online.de (Desktop webmail)
36. Free.fr (Desktop webmail)
37. GMX (Desktop webmail)
38. GMX (iOS)
39. GMX (Android)
40. WEB.DE (Desktop webmail)
41. WEB.DE (iOS)
42. WEB.DE (Android)
43. 1&1 (Desktop webmail)
44. 1&1 (Android)

Testing methodology

For a HTML/CSS feature to be tested, a reduced test case is created and sent to various inboxes. The rendered code by the email client is examined to determine whether an email client supports a feature.

Email client results

Email clients that support all 20 tested accessibility features:

Only one email client (SFR Desktop webmail) supports all 20 accessibility features.

Email clients that support fewer than 5 out of the 20 tested accessibility features:

• T-online.de (Desktop webmail): 2/20 features supported
• Free.fr (Desktop webmail): 4/20 features supported
• Outlook (Windows mail): 4/20 features supported
• AOL (iOS): 4/20 features supported
• GMX (Desktop webmail): 4/20 features supported
• GMX (Android): 4/20 features supported
• WEB.DE (Android): 4/20 features supported
• 1&1 (Android): 4/20 features supported
• WEB.DE (Desktop webmail): 3/20 features supported

Commonly unsupported accessibility features

• ARIA attributes: such as aria-label, aria-labelledby, and aria-describedby. These can be crucial for screen readers to convey contextual information.
• CSS pseudo-classes: such as :hover, :focus, and :active. These can be used to enhance keyboard navigation and interactivity.
• CSS Media Queries: such as @media (prefers-color-scheme) and @media (prefers-reduced-motion). These can be used to allow for adaptations based on user preferences.

Gmail

At the time of writing, none of the Gmail email clients support key features that allow developers to respect user preferences such as @media (prefers-color-scheme) and @media (prefers-reduced-motion). For a company that actively promotes an accessible web, Gmail’s lack of support for such features is a notable inconsistency.

Outlook

The legacy Outlook for Windows desktop app only supports 7 out of the 20 tested features. Given its market share, this just means a lot of its users have inaccessible experiences. This is especially problematic in enterprise and government use cases where compliance is mandated and often users don’t get a choice of email client to use.

The good news is that Microsoft is deprecating this version of the app and they are working towards a more unified approach for rendering HTML emails across their email clients, all of which are scoring better than the legacy Outlook for Windows. This move will have a big impact on a decent percentage of users worldwide.

Yahoo

Yahoo Mail (on all operating systems) has a similar score to the legacy Outlook for Windows desktop app: 7 out of 20. This is concerning for a major email client running on a modern stack (unlike the legacy Outlook for Windows which uses Microsoft Word as a rendering engine). It is also disappointing given Yahoo is one of the few email clients that decided to support AMP for email, but didn’t put the effort to improve the accessibility for the largest percentage of its users.

Conclusion of email client accessibility

The state of accessibility in email clients reflects the broader challenges facing the email ecosystem: a lack of coordination, missing standards, and uneven support for fundamental features.

The Email Markup Consortium is looking to help close these gaps. Our mission is to bring greater consistency to how email clients handle code and to empower everyone to build better, more inclusive experiences. Accessibility isn’t an optional enhancement; it’s a core part of delivering reliable, user-centered communication.

Real change will require a commitment from the email clients to implement and maintain support for accessibility standards. As well as commitments from senders to create and send more accessible messages. By working together toward an open, reliable, and inclusive email ecosystem, we move closer to a future where no user is left behind.

If you have found this report helpful, please consider a small donation via our Open Collective page. We rely on donations to keep this report and other projects running.