How to fix email accessibility issues with AI

In this article

Almost every email you send has an accessibility issue in it. When the Email Markup Consortium tested 376,348 HTML emails sent between May 2025 and May 2026, all but eight of them contained problems flagged as serious or critical.

Two issues sit at the top of that list every year, and they're both quick to fix: missing dir attributes on the email body (97.41% of emails) and missing body-level lang attributes (95.66%). Neither one changes how your email looks. Both change how it reads for people using screen readers or a different system language.

Automated checkers are good at catching whether an attribute is present. They can't tell you whether the value is correct, or whether a bold line of text should have been a heading. That gap is where an AI review and a human pass earn their place. Below is how the top two issues break the experience, and how a layered testing approach catches the ones an automated tool leaves behind.

TLDR

The most reliable approach is three layers: run an automated test first, an AI review second, and a manual check last. The automated pass clears the obvious structural bugs, the AI pass adds context that an automated rule can't reach, and the human pass settles the judgment calls.

The EMC 2026 accessibility report found that 99.88% of the HTML emails it tested contained serious or critical accessibility issues.
The two most common issues are missing dir (97.41% of emails) and missing body-level lang (95.66%), year after year.
You need to repeat lang and dir inside the body of your email, because many webmail clients strip the <html> tag before displaying your code.
Automated tests confirm an attribute exists but don't validate that its value matches the content, so a lang="fr" set on English copy still passes.
AI-based review reads the content, so it can catch a language mismatch, spot text that reads like a heading without heading styling, and flag vague link text across multiple languages.

Why lang and dir top the accessibility issue list every year

They control how a screen reader pronounces your email, and most emails never set them where they need to be set. The lang attribute tells assistive technology which language your content is written in. When it's wrong or missing, the screen reader uses the wrong voice.

Here's what that sounds like in practice. Take a heading written in French: "Pourquoi lang et dir sont des attributs importants dans les e-mails HTML." With lang="fr" set, a screen reader reads it in a French voice with French pronunciation. With no language set, the same French text gets read with an English voice and English pronunciation. Set the wrong language, say lang="es", and it gets a Spanish voice reading French words. Different languages can share the same spelling with different meanings, so the wrong voice can change how someone interprets the message.

The catch is where you set it. On the web, you'd put lang and dir on the <html> tag and move on. In email, webmail clients often strip the <html> tag, along with the doctype, head, and body, leaving you with only the content. Once that happens, your email inherits whatever language and direction the client itself is set to. So you need to repeat the attributes on an element inside the body:

html

<div lang="en" dir="ltr">
  <!-- all of your email content -->
</div>

Setting lang on both the <html> tag and a wrapper inside the body covers you whichever way the client renders your code.

What the dir attribute fixes

The dir attribute controls text direction, and without it, your layout inherits the reader's client direction instead of your content's. If someone has their email client set to a right-to-left language like Arabic, but your email is written in English, the client applies right-to-left direction to your left-to-right content.

The result is a layout that looks broken: text aligns right instead of left, bullet points sit on the right of the text, punctuation lands in the wrong place, and multi-column layouts swap their order. Setting dir="ltr" on the direct children of the body keeps your intended direction regardless of the reader's client.

You'll sometimes see dir="auto" used as a fallback. It's acceptable, since it lets the client work out direction from the content, but setting the direction explicitly removes the ambiguity. If you know your content is left-to-right, say so.

Where do automated accessibility tests fall short?

They check that an attribute is present, but not that its value is correct. An automated test will see lang="fr" and pass it, even when every word in the email is English. That's a false positive: the markup is there, but it's wrong.

The reverse happens too. Say you've wrapped all your content in a <div> with lang and dir set correctly, but your sending tool inserts preheader text before that div without the attributes. If the preheader is set to display:none, it never shows, so a manual test passes. An automated test isn't always sophisticated enough to know the hidden text will never render, so it fails you for something no reader will ever encounter.

There are also issues that need interpretation rather than detection:

Alt text versus decorative images. A checker can see an image is missing alt text. It can't easily tell that the image sits next to descriptive copy that already covers it, which might make it a decorative image. Even accessibility experts disagree on how to handle this, so it needs human judgment.
Text that should be a heading. A line that's large and bold can present like a heading while being coded as a paragraph, which loses the semantic meaning a screen reader relies on. Reading style alone, or context alone, can reveal that.
Vague link text. "Find out more" tells a screen reader user nothing about where the link goes. Automated tools catch some of these by matching against a predefined list of phrases, but that list is finite.

How does AI catch what automated tests miss?

AI reads the content, so it can validate meaning instead of only checking for structure. In Design Studio, you can run an email accessibility skill by asking your AI Agent to check the accessibility of an email. It runs against the same email an automated test would, and picks up the context-dependent issues an automated rule can't.

In practice, that means it can:

Detect that the code says lang="fr" while the content is written in English, because it can read and identify the language of the copy.
Look at a missing-alt-text image sitting beside descriptive text and suggest treating it as decorative, while flagging it for your review rather than deciding for you.
Recognize that a bold "Save as template" line is functioning as a heading and should carry a heading element, sometimes from context alone, even without the styling.
Expand vague-link detection beyond a fixed list to any non-descriptive link text, across multiple languages.
Flag a dir="auto" that could be set explicitly, and catch center-aligned text that reads fine on desktop but runs to six hard-to-read lines on mobile.

Once you approve the suggestions, it can apply the fixes and re-check, then keep surfacing the remaining judgment calls as things to be aware of rather than as errors. Alongside the Design Studio version, there's a more generic accessibility skill that works on any HTML email, with no platform-specific pieces in it, available for anyone to use on GitHub.

The right testing workflow: automated, then AI, then manual

Run the layers in order and let each one do the job it's best at. Automated first, AI second, manual last.

Automated test. Clears the obvious, machine-checkable bugs quickly: missing attributes, missing alt, layout tables without a role.
AI review. Adds a layer of context and intuition to catch the more complex issues, like a language value that doesn't match the content or a paragraph that should be a heading.
Manual review. Settles the judgment calls that reasonable people disagree on, and confirms everything reads the way you intended.

None of these replaces the others. The automated pass is fast and consistent, the AI pass reaches issues that rules can't express, and the human pass makes the final call.

FAQ

Why do I need lang and dir inside the body if I've set them on the <html> tag? Many webmail clients strip the <html> tag before displaying your email, along with the doctype, head, and body. When that happens, your content inherits the client's own language and direction settings. Repeating lang and dir on a wrapper element inside the body keeps your settings intact whichever way the client renders your code.

What's the difference between dir="auto" and dir="ltr"? dir="auto" lets the email client determine direction from the content, which is acceptable as a fallback. dir="ltr" states the direction explicitly and removes any ambiguity. If you know your content is left-to-right, setting it explicitly is the safer choice.

Can automated accessibility tests give false results? Yes. They confirm an attribute is present but don't validate its value, so a wrong lang still passes (a false positive). They can also fail correctly marked-up emails when a sending tool inserts hidden preheader text without the attributes, even though that text never renders (a false negative).

Should I avoid center-aligned text in email? Center alignment isn't an issue on its own, but it becomes harder to read once it runs past three lines. Text that fits on three lines on desktop can wrap to six on mobile, so check the mobile preview and switch to left alignment if it stretches.

How is an AI accessibility review different from an automated checker? An automated checker matches your code against a fixed set of rules, so it's fast and consistent but limited to what those rules can express. An AI review reads the content, which lets it validate that a language value matches the copy, judge whether an image is decorative, and flag non-descriptive link text across languages.

Where can I run these checks on my own HTML emails? There's a generic version of the accessibility skill that works on any HTML email, with no platform-specific pieces, published on GitHub.

Keep up with email development

Mark posts new email development walkthroughs on the Mr. Email Dev channel, covering CSS support, email bugs, accessibility, and using AI in email. Subscribe on YouTube to catch each one.