Guide · October 2026

The email accessibility checklist: WCAG 2.1 AA for HTML email

An HTML email is a web page that somebody else’s software renders. Screen readers read it, people zoom it, people see it in dark mode and in colour-blind vision, and in the EU since June 2025 the law expects it to work for all of them. The good news is that nearly every accessibility check is mechanical: a contrast ratio, an attribute, an order. This is the checklist, mapped to the WCAG 2.1 AA criteria that actually apply to email, with what fails most in real campaigns.

If you only have ten minutes: run the contrast and alt-text passes. Between them they cover most of the failures that reach a complaint.

Which WCAG criteria apply to email

WCAG has 50 success criteria at AA. Most are about forms, video, navigation and timing, which an email does not have. These are the ones that do apply, in plain words:

1. Structure and language

• The <html> element has lang set to the email’s language, and dir="rtl" for Arabic, Hebrew, Persian or Urdu. A screen reader picks its voice from this.
• The <title> is the subject line, not “Untitled” or the ESP template name.
• Every layout table carries role="presentation" (or role="none"). Without it, a screen reader announces “table, 3 rows, 1 column” before every module.
• Real data tables (rates, fees, dates) keep their <th> headers with scope, and no presentation role.
• Headings are real <h1> to <h3> elements, one per section, in order, with no level skipped. Bold paragraphs are not headings.
• The reading order in the code is the order a person should hear it. On a two-column layout, check what happens when it stacks on a phone.
• Lists are <ul> or <ol>, not paragraphs with bullet characters.

2. Text

• Body copy is at least 14px; 16px reads better on a phone. Legal copy never goes under 10px, whatever the brand guide allows.
• Line height is at least 1.4 for body copy, and nothing is clipped when the reader increases text spacing.
• No live text is locked inside an image. A headline drawn in the hero can’t be read aloud, resized, translated or searched.
• Text in pixels is fine; text in viewport units or with -webkit-text-size-adjust: none is not, because it stops the reader from zooming.
• Sentences are short and the point comes first. A screen reader user hears the email in order and cannot skim.
• Hidden preheader text is hidden from everyone, not only from sighted readers: use display:none plus mso-hide:all, not white-on-white text, which a screen reader reads out twice.

3. Colour and contrast

• Every text and background pair reaches 4.5:1, or 3:1 for large text. Check the footer, the legal block and placeholder-grey copy first.
• Buttons, icons and dividers that carry meaning reach 3:1 against their surroundings. A pale green button on white is the classic failure.
• Links are told apart from body copy by more than colour: an underline, or 3:1 contrast with the surrounding text plus a change on hover.
• Nothing is explained by colour alone (“items in red are sold out”); the information is also in the words.
• The email still reads under the common colour-blind simulations: red and green used for pass and fail are the usual casualty.
• Dark mode: a transparent logo on a dark background, text that stays readable when Gmail inverts the colours, no black-on-black buttons.

4. Images and alt text

• Every image has an alt attribute. Content images describe what the image shows in one short sentence; decorative images (spacers, dividers, backgrounds) have alt="".
• A linked image’s alt text says where the link goes (“Activate my bonus”), not what the picture is of.
• No alt text is a file name, “image”, “banner”, a number, or the same on two different images.
• Alt text is in the email’s language. A French email with English alt text reads as a bug to a screen reader user.
• No image is a picture of a paragraph. If the words matter, they are live text; if they must be an image, the alt text carries the words.
• Animated GIFs do not flash more than three times a second, and the first frame makes sense on its own, because Outlook shows only that.
• Images have width and height attributes, so the layout holds its shape while images load or when they are blocked.

Writing alt text for twenty images is the slow part. The free alt text writer drafts it in copy-deck style from the image itself, and the image checker finds the ones that are missing it.

5. Links and buttons

• Link text says where the link goes. “Click here”, “Learn more” and “Read more” on their own are failures when read out of context, which is how a screen reader lists links.
• Every link has a real href: no empty value, no #, no javascript:.
• Buttons are at least 44 by 44 pixels of tappable area, with padding on the link itself rather than the cell around it.
• No title attributes carrying content. Screen readers handle them inconsistently, and touch screens never show them.
• Two links with the same text go to the same place. “Learn more” three times to three pages is a maze when read as a list.

6. Motion and flashing

• Nothing flashes more than three times in a second, anywhere in the email, at any size.
• Animation stops on its own, or is short enough that it does not need to. A looping GIF beside body copy makes the copy hard to read for many people.
• Nothing depends on hover. Phones have no hover, and neither do most screen readers.

7. The plain-text version

• There is one, and it says the same thing as the HTML, in the same order, with the links written out.
• It is not the ESP’s automatic strip of the HTML with the navigation and the alt text mashed together.

How to test it

Automated checks find the measurable failures: contrast, missing alt, missing roles, font sizes, link targets, heading order. Three manual checks catch the rest, and together they take ten minutes.

• Listen to it. VoiceOver on a Mac or iPhone, NVDA on Windows. Does the order make sense, do the images say something useful, do the links say where they go?
• Zoom it. 200% in a desktop client, and the largest text size on a phone. Nothing should clip, overlap or scroll sideways.
• Turn the colours off. Grayscale and dark mode. If a state or a button disappears, colour was doing too much work.

What fails most in real campaigns

• Grey legal copy at 11px on a tinted footer: contrast and size at once.
• Layout tables without a presentation role: dozens of them, in every email from the same template.
• Alt text that is the file name, or is present on the English version and missing on the French one.
• The hero headline drawn into the image, so the one line that matters cannot be read aloud.
• “Learn more” as the text of every button.
• A pass and fail shown as green and red with no other cue.

Running it on every build

SendLint runs the measurable half of this list on every email, in one pass with the rest of the QA: contrast (and the colour-blind simulations), minimum font size, alt text presence, quality, uniqueness and language, table roles, heading structure, link targets, text resize and reflow, text spacing, non-text contrast, sensory wording, title attributes and the inbox preview. Every finding carries the element, the colours and the measured ratio, which is what your developer needs to fix it in one round.

This is pass 5 of the full email QA checklist. For what the brand guide says about colours and type, and how to turn it into rules, see brand guide PDF to email QA rules.