Accessibility Report 2026

Last modified: 21 May 2026

This report serves as a technical audit of the senders, platforms and email clients that define the modern inbox. The results below are from analysis of over 376,000 emails across senders and geographies, looking at how each email scored on a detailed accessibility scorecard. This year’s report also looks beyond the sender, including views of widely used newsletter platforms with built-in email build/authoring tools.

The 2026 Email Accessibility Report reveals an industry at a technical standstill. Despite a marginal uptick, the email ecosystem remains in a state of systemic failure: 99.88% of the 376,348 emails analyzed this year contain ‘Serious’ or ‘Critical’ accessibility defects, leaving only a 0.002% pass rate represented by just eight emails from three brands.

In this year’s report, we are also looking beyond the sender and at widely-used newsletter platforms with built-in email build/authoring tools. We audited 10,566 emails sent via Substack, Shopify and Beehiiv. None passed our automated testing.

When it comes to email clients, we have taken a deeper look this year, nearly doubling our email client accessibility criteria from 20 to 37 feature benchmarks. The data is clear: a major reason why accessibility is failing in email is a lack of implementation.

Result

• 99.88% of HTML emails tested contain accessibility issues categorized as “Serious” or “Critical”.
• Only 8 emails (0.002%) passed all accessibility checks. These emails came from just three separate brands!
• The majority of the issues are not edge cases. These are basic, machine-checkable accessibility failures.
• No email clients support 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:

• The Knowledge Gap (senders): Traditional web accessibility standards do not always translate to the unique constraints of the inbox. Developers often overlook email-specific requirements
• The Tooling Gap (build tools): While drag-and-drop builders have improved, many still generate HTML that prioritizes layout over semantics. Platforms often fail to expose critical accessibility fields like language settings to the end user, making it impossible for a sender to be compliant.
• The Rendering Gap (email clients): Email clients continue to strip or ignore key accessibility features. Without consistent support for these features, developers are forced into “hacky” workarounds or are unable to produce compliant code.

What Needs to Change

This report is a call to action for shared responsibility:

• Senders: Move beyond standard visual rendering QA. Use automated auditing tools like Parcel’s accessibility checker to catch machine-checkable errors before deployment.
• Template and ESP tools: Audit your generated markup. Set better defaults and fallbacks. Add automated accessibility checks. Guide users into creating accessible content.
• Email clients: Support HTML/CSS features needed to author accessible code.

A Few Leading the Way

Senders

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

Achieving these results requires a QA process where accessibility is equal in importance to visual rendering. Currently, most senders prioritize rendering across email clients but do not pay enough attention to how accessible their messages are.

And to scale these results, high-performing teams are moving toward accessible design systems. By enforcing accessibility into a single source of truth or a shared component library, fixes are implemented once and propagated globally. This eliminates the “human error” from every individual campaign and allows for meaningful iterations and improvements over time.

Email clients

This year we nearly doubled our email client accessibility criteria from 20 to 37 feature benchmarks. No client supports all of them, but we recognize the progress from leaders like Apple Mail (34/37 on macOS), Samsung Email (31/37), and Proton Mail (29/37).

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 that applies to an accessibility feature, suitable workarounds or fallback options should be provided. The EMC would love to work closely with more 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 2025 and May 2026. We collected 376,404 emails from multiple industries across multiple languages.

• Number of emails collected between May 2025 and May 2026: 376,404 (~15% fewer than last year)
• Number of emails that could not be analyzed (due to invalid code): 56
• Number of emails analyzed: 376,348

To learn more about and help expand our dataset of emails, visit the Data Collection Project.

The Email Markup Database

In alignment with our commitment to transparency and collaboration, the broader trends of our data can be found on the Email Markup Database, which serves as a comprehensive, continuously updated repository of real-world HTML and CSS usage metrics in email.

Testing methodology

Accessibility testing for this report 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 looks at 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 - Mild impact issues are those issues that are like bugs that are difficult to replicate or occur intermittently. You can consider fixing these issues only if you find a low-risk solution.

• Moderate - Moderate impact issues are those issues that result in lesser impact on users than serious issues. While your end-user may appreciate a fix or patch, it won’t necessarily impact their ability to use or interact with the website.

• Serious - This issue results in some barriers for individuals with disabilities but would not prevent them from accessing fundamental elements or content. Serious impact issues are those issues where users with disabilities encounter some obstacles as a result of this problem, but it does not prevent them from accessing fundamental components or content.

• Critical - Critical impact issues are those issues that have significant obstacles for people with disabilities. Users who depend on assistive technology can get frustrated while trying to access the content. Some content that is inaccessible may make the organization vulnerable to legal action. This results in the issue preventing the website from being used successfully.

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

From this we can see that 99.88% 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 8 (0.002%) passed without issue. Those emails came from just three senders:

• Customer.io
• NaomiWest.ca
• Noble Panacea

Emails that pass our checks may still have accessibility issues that we cannot pick up through automated testing.

After manually testing the 8 passing emails, we found both Customer.io and NaomiWest.ca had small issues with alt text not matching text in images well enough.

For Noble Panacea, we found a few issues:

• Alt text not matching text in images
• Alt text lacking description for detailed images
• Very small text in images was unreadable on narrow viewports
• Generic alt text on a decorative image
• Hidden characters in alt text
• 10px font size on footer text

As well as issues with emails that pass tests, 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 97.41% (366,558) 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, as it allows the user agent to make a judgement rather than inheriting the value set on the email client.

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

Issue present in 95.66% (359,950) 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 83.78% (315,272) 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 74.23% (279,325) 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 71.23% (268,049) 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 62.16% (233,886) 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 58.48% (220,038) 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 47.88% (180,171) 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 45.21% (170,132) 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 15.83% (59,577) 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.

Comparing to the rule set from previous years

The shift from 99.89% (2025) to 99.88% (2026) in Critical and Serious issues is small statistically. However, the underlying data reveals a shift in how emails are failing and improving.

We are seeing consistent, incremental improvements in basic tag attribute-level compliance (dir, lang, alt, and role). This trend correlates with how modern email frameworks and visual email build tools are adopting an “accessibility-by-default” philosophy.

The only rule that has increased in percentage of tested emails is, “Missing <title> element”, this is mainly a rule for the “view in browser” link that many emails include. If there is no browser version, or if the browser version has a <title> inserted into it, then this rule doesn’t matter and the email would pass manual testing.

The data suggests things are improving or at minimum the industry is learning to “pass the test”. This is a good start. We recommend senders include automated testing as part of their QA workflow. However, accessibility isn’t a simple checklist and manual testing remains more reliable and is highly needed in the industry.

Industry break down

For this year’s report, we again 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 115 emails from education domains. 100% triggered at least one failure in our automated accessibility testing. 2% with Critical issues and 98% with Serious issues.

Only 2 emails failed with a Critical issue, and that was the same issue across both. Images must have alternate text.

The rest of the messages failed with serious issues.

100% of emails had the following serious issues:

• Documents must have <title> element to aid in navigation
• Content inside the body should be wrapped in a dir attribute
• Content inside the body should be wrapped in a lang attribute

And all but 1 email had tables used for formatting that should have the role attribute set to presentation or none.

On the positive side, we’re not seeing many emails with missing alt attributes in images, only 1.74% compared to overall 47.88%. And we didn’t detect any color contrast issues. The sample size is small but it’s a good sign.

Government

We found 2,124 emails from government domains. 100% triggered at least one failure in our automated accessibility testing. 7% with Critical issues and 93% with Serious issues.

The most common Critical issue was Images must have alternate text (5.3%), we’re also seeing about 1.6% with VML must have alternate text (34 emails). As well as issues with Zooming and scaling must not be disabled (14 emails).

For Serious issues;

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

Government results for missing alt attributes in images are also lower than overall results, 5.32% compared to overall 47.88% and links without discernible text is down from 71.23% overall to just 17.42% in government emails.

Marketing and Newsletter Platforms

For this year’s report we’ve additionally audited a new category of senders: marketing and newsletter platforms that own the HTML code of the emails sent by its customers.

The newsletter platforms are Substack and Beehiiv. These platforms do not allow its users to upload a custom email template. Hence the HTML in any email sent by these platforms was under the platform’s control. We only audited emails sent from their domains.

The marketing platform is Shopify’s built-in email marketing solution. The platform provides a visual email builder. While it also provides the ability to upload custom HTML, we only looked at ecommerce brands sending their marketing emails using Shopify’s default sending domain shopifyemail.com. A brand not sending marketing emails from its own domain is unlikely to be using custom HTML.

We detected 6,909 Substack emails, 1,468 Shopify emails, and 2,189 Beehiiv emails. These have only been tracked for the last six months, however emails from these senders may still appear in the full twelve months of data used elsewhere in this report. 100% of the emails found from each of these platforms failed our testing.

These results don’t necessarily reflect issues with the platforms. The issues could also come down to user choices. However, it is the responsibility of these platforms to help guide their users toward more accessible choices.

Substack

100% of emails were found to be missing internal lang and dir attributes (Content inside the body should be wrapped in a dir attribute, Content inside the body should be wrapped in a lang attribute). However, a small number of emails (14.2%) were found to have lang set on the <html>. This suggests it is possible to set a language; it is just not being applied correctly in the body.

99.96% of emails had color contrast issues (Element has insufficient color contrast). Only 3 emails out of the 6,909 didn’t have this issue. This is surprisingly high and suggests an underlying issue. Perhaps default text with poor contrast, or some dark mode issues.

97.37% of emails were missing link text (Links must have discernible text). This is often caused by linked images without alt text.

Shopify

100% of emails were also found to be missing all internal lang and dir attributes. For Shopify, 100% were also missing HTML lang attributes (<html> element must have a lang attribute). That suggests the language setting is either hard to find or not exposed to users.

99.59% of layout tables were missing a role attribute (Tables used for formatting should have the role attribute set to “none” or “presentation”). Only 6 out of 1,468 emails passed.

Beehiiv

100% of emails were found to be missing dir attributes. Almost all passed the lang check, only 8 emails (0.37%) failed it. That points to a potentially straightforward automated fix: infer the correct text direction for the language and set dir accordingly.

99.59% of emails had non-descriptive link text (Link text should be descriptive). Such a high percentage suggests something systemic, such as poor default link text. Only 9 emails out of 2,189 did not have this issue.

92.55% of emails were missing link text (Links must have discernible text). Often caused by linked images without alt text.

Limits of automated testing

Passing automated testing does not guarantee real-world accessibility. Automated testing tools, like Parcel’s accessibility checker, are great at verifying the presence of compliant syntax or comparing computed values against accessibility guidelines, but they cannot evaluate intent.

For example, an automated checker can verify that an <img> tag has an alt attribute, but it cannot determine if the alternative text is suitable for that image in the context of that message.

Another context-dependent example is the missing <title> element. While critical to aid browser-tab navigation in the “View in Browser” (web fallback) version of the email, it is functionally redundant if an email doesn’t provide a web fallback.

Advances in AI can help bridge the gap between automated syntax checking and manual inspection by picking up some of the more nuanced issues such as:

• Localization: validating the values of the lang and dir attributes against the language used in the email.
• Image analysis: checking the value of the alt attribute against the image content, as well as looking at the context in which the image is used in the email.
• Link evaluation: evaluating whether the link text provides a clear description of the destination based on the context rather than simply comparing the text to to a list of common phrases.
• Design and code alignment: Checking semantic markup against design and content.

However, this is still not a replacement for manual testing. It’s just a way to help speed up the process and catch some of the more common issues. Manual testing is still required to ensure the email is accessible to all users.

Conclusions

While a number of individual developers, email frameworks and email build tools have made improvements, the real-world impact is being diluted by a massive volume of HTML emails poorly created by a combination of legacy tools, unguided user behaviour and uneducated developers. The fact that simple tag attribute failures still dominate our top 10 issues proves this.

There is a real need to shift accessibility checks from a post-build step to an integrated always-on process during build. Email frameworks and visual builders need to implement real-time linting and constraints warning their users of accessibility issues they’re producing. As a user selects a color, run a contrast check. As a user adds an image, help them with alt text. As they add a heading, make sure it’s not skipping levels.

Senders cannot fully work around email client limitations and produce fully accessible HTML messages. When an email client intentionally strips or alters semantic markup it has a clear responsibility to document these breaking changes. The data in the next section backs this.

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.

To reflect the constant evolution of modern front-end development, we have expanded our email client accessibility criteria this year from 20 to 37 core HTML/CSS features, which represent the technical stack required to author semantic and accessible HTML messages. These features are essential for adaptive rendering, focus management, keyboard navigation and assistive technology compatibility.

The following 37 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. color-scheme CSS property
5. cursor
6. font-size-adjust
7. light-dark()
8. :active
9. :default
10. :focus-visible
11. :focus-within
12. :focus
13. :hover

HTML features:

1. inert attribute
2. <abbr> element
3. aria-describedby attribute
4. aria-hidden attribute
5. aria-label attribute
6. aria-labelledby attribute
7. aria-live attribute
8. <blockquote> element
9. <code> element
10. <dfn> element
11. dir attribute
12. <h1> to <h6> elements
13. hidden attribute
14. <hr> element
15. <img> element
16. lang attribute
17. <ul>, <ol> and <dl>
18. color-scheme meta tag
19. <p> element
20. <picture> element
21. role attribute
22. <ruby> element
23. HTML5 semantics (<article>, <aside>, <details>, <figcaption>, <figure>, <footer>, <header>, <main>, <mark>, <nav>, <section>, <summary>, <time>)
24. <table> element

These features were tested on 43 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. Samsung Email (Android)
21. SFR (Desktop webmail)
22. SFR (iOS)
23. SFR (Android)
24. Orange (Desktop webmail)
25. Orange (iOS)
26. Orange (Android)
27. Proton Mail (Desktop webmail)
28. Proton Mail (iOS)
29. Proton Mail (Android)
30. HEY (Desktop webmail)
31. Mail.ru (Desktop webmail)
32. Fastmail (Desktop webmail)
33. LaPoste.net (Desktop webmail)
34. T-online.de (Desktop webmail)
35. Free.fr (Desktop webmail)
36. GMX (Desktop webmail)
37. GMX (iOS)
38. GMX (Android)
39. WEB.DE (Desktop webmail)
40. WEB.DE (iOS)
41. WEB.DE (Android)
42. 1&1 (Desktop webmail)
43. 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. This is a very manual process. Plus, the lack of documentation by email clients makes it harder to know what to test (or re-test). As a result, a delay in reflecting the feature support for each email client is expected.

We encourage transparency. If you are an engineer or a product owner working on an email clients, you can update your product’s data on Can I Email?. Proton Mail is now a regular contributor. Jen Simmons from Apple (Safari & Webkit) is another notable contributor to the project.

Email client results

This report looks at how well HTML and CSS used inside email messages are supported when those messages are rendered in a client. It does not assess the accessibility of the email client application itself. For example, the client’s own interface, keyboard navigation, or how well the client works with assistive technology is not part of the audit.

No email client currently supports all 37 accessibility features, but there are notable results.

1. Apple Mail: The highest score is 34/37 (Apple Mail on macOS). However, those 3 failing tests all have partial support.
2. Samsung Email is second with a score of 31/37, only has 2 failing tests, one point is lost for a partially supported test and 3 are untested.
3. Proton Mail scored 29/37. We are in communication with the team and know they have been doing a lot of good work and allocating regular resource for this.

The table below lists every client tested and how many of the 37 features it supports.

Clients with the weakest scores

More than half of the tested clients (25 of 43) supported fewer than half of these accessibility-related features—that is, 18 or fewer out of 37. Many sit in the single digits or low teens, which leaves large gaps for authors who want to use semantic HTML, ARIA, or modern CSS safely.

Commonly unsupported accessibility features

• ARIA attributes (for example aria-label, aria-labelledby, and aria-describedby): important for screen readers to convey structure and context.
• CSS pseudo-classes (for example :hover, :focus, :focus-visible, :focus-within, :active, and :default): useful for visible focus, keyboard affordances, and interactive states.
• CSS preference media queries (for example @media (prefers-color-scheme) and @media (prefers-reduced-motion)): needed to respect system appearance and user preferences.
• Other CSS that often lags in clients includes color-scheme, light-dark(), cursor, font-size-adjust.

For some of the newer CSS features like light-dark(), it’s understandable that email clients may be a bit behind web. However, for features like :hover, :focus that have been in the CSS specification since 1998 and have been supported by all modern browsers for a long time, it’s very disappointing to not support them for email as well.

Gmail

Gmail’s scores in this set range from 15/37 (iOS, Android, and mobile webmail) to 17/37 (desktop webmail). At the time of writing, Gmail still does not support key preference-driven features such as @media (prefers-color-scheme) and @media (prefers-reduced-motion) in a way authors can depend on. The issue is made worse by the forced dark mode that Gmail enforces, which takes control away from the sender and often results in color contrast issues.

For a company that promotes an accessible web, that gap remains a notable inconsistency. Google has been listed in 2026’s Forbes Accessibility 200. It is recognized globally for its good accessibility work. This makes it really difficult to reconcile their excellent accessibility work in the digital space with the limited support for accessibility-related features in Gmail, one of their main products.

Outlook

Outlook’s results are split by platform: Outlook (Android) is among the stronger clients (25/37), while Outlook (Windows) (11/37) and Outlook (Windows mail) (8/37) sit much lower. Outlook (outlook.com) scored 20/37, and Outlook (macOS) and Outlook (iOS) each scored 22/37. The legacy Outlook for Windows desktop app still leaves many accessibility-oriented features unsupported for a large share of enterprise and government users who cannot choose another client.

The good news is that Microsoft is deprecating the legacy Windows app and moving toward a more unified rendering story across its clients; several Outlook surfaces already score meaningfully higher than classic Outlook for Windows in this feature set.

The ongoing retirement of legacy Outlook rendering engines on Windows presents a major opportunity for accessibility improvements across the Microsoft email ecosystem. The step Microsoft is taking here makes the goal of enforcing markup standards in the email industry more feasible.

Yahoo

Yahoo Mail scored 16/37 on desktop webmail and on Android, and 14/37 on iOS. That is stronger than the lowest-tier clients but still only mid-pack for a major consumer client on a modern stack. It remains disappointing that investment in capabilities such as AMP for email has not translated into broader, baseline accessibility feature coverage for everyday HTML email.

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 rejects the notion that the inbox must remain a sub-standard tier of the web. Regardless of the lack of markup standards in email, given the regular advances in front-end technology, the poor state of accessibility in email clients is a reflection of architecture and product choices.

We urge email clients to audit their HTML sanitizers on a regular basis. Security constraints do not require the stripping of most (if not all) of the accessibility-related HTML/CSS features in our benchmark.

Real change requires email clients to treat accessibility support with the same engineering attention allocated to security, performance and privacy. It requires a commitment from the email clients to implement and maintain support for accessibility standards. Commitments from senders to create and send more accessible messages cannot go beyond the limits imposed by email clients.

We believe email clients, ESPs, build tools and senders can work together toward an open, reliable, and inclusive email ecosystem. This ultimately benefits the end users (recipients) the most. In order to get there, all parties must understand their role and responsibility in this unique ecosystem.

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.

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.