# Email Accessibility Checker and WCAG Evidence Audit

> Inspect email HTML for source-level accessibility evidence, preserve every finding and remediation action, and carry a precise manual test plan into rendered-client review.

- **Canonical page:** [https://emailbump.com/tools/email-accessibility-checker](https://emailbump.com/tools/email-accessibility-checker)
- **Interactive tool:** [Open the email accessibility checker](https://emailbump.com/tools/email-accessibility-checker)
- **Category:** accessible email design, source review, and quality assurance
- **Standard reference:** Web Content Accessibility Guidelines (WCAG) 2.2
- **Updated:** July 2026
- **Privacy:** HTML and text supplied to the tool are parsed locally in the browser
- **Network boundary:** The checker does not upload, store, render remotely, or send the supplied email
- **Decision boundary:** Results are bounded source evidence, not WCAG certification, a legal opinion, an assistive-technology test, or proof of the final delivered experience

## What this tool is for

Email accessibility work has two different layers. The first is evidence visible in the source: whether the document declares a language, whether images have explicit alternative-text decisions, whether links have names, whether headings exist in a plausible hierarchy, whether data tables retain relationships, and whether explicit opaque color pairs meet the applicable contrast threshold. The second layer exists only after the message is built and delivered: reading order, client transformations, zoom and reflow, screen-reader behavior, dark mode, animation timing, background imagery, and the final MIME structure.

This checker keeps those layers separate.

It identifies deterministic source failures, flags suspicious patterns, creates manual-review gates when automation cannot establish the result, and records affirmative evidence where a bounded source test passes. It deliberately does not collapse that evidence into a percentage or an invented accessibility score. A score would hide which conditions were tested, which were inferred, and which were never observable.

Use the tool when:

- reviewing an email template before it enters an editor or provider;
- auditing a built HTML artifact before a campaign or transactional release;
- comparing revisions during accessibility remediation;
- turning source findings into an engineering, design, or content handoff;
- creating a repeatable preflight gate in a release process;
- documenting which rendered tests remain after static analysis;
- checking that a plain-text alternative exists alongside the HTML review.

Do not paste live secrets, recipient data, signed URLs, authentication tokens, or private identifiers. Local analysis reduces network exposure, but sensitive production data does not belong in a browser utility unless it is necessary and authorized.

## Evidence states

The tool reports an evidence state rather than a conformance score.

### Source failures

A source failure is a condition the parser can establish from the supplied markup. Examples include an image with no alt attribute, an unnamed link, an empty heading, an interactive role with no resolvable name, a missing document language, a broken aria-labelledby reference, or an explicit text color pair below the applicable WCAG ratio.

These findings should normally block a release until they are corrected or a reviewer demonstrates that the parser misunderstood the source. The export includes the category, criterion reference, source evidence, explanation, and proposed action.

### Suspicious patterns

A warning identifies source that is probably risky but needs context. Filename-like alternative text, a skipped heading level, ambiguous link wording, positive tabindex, a large fixed width, implicit data-table relationships, and duplicate IDs are examples.

A warning is not automatically a WCAG failure. It means the implementation deserves inspection because common failures use the same pattern.

### Manual-review gates

A manual gate marks a question that static source cannot settle. Whether an alternative describes the image's purpose, whether “Learn more” is clear from its surrounding sentence, whether a table is truly layout or data, whether animation flashes, whether the visual and source reading orders agree, and whether a message reflows in a specific client all require human or rendered testing.

Manual gates are expected. An email with no parser failures can still require many of them.

### Pass evidence

Pass evidence records a bounded fact, such as every image having an alt attribute or all explicit resolvable inline color pairs meeting their source-level thresholds. It does not mean the whole success criterion passes. For example, a correct alt attribute can still contain the wrong description, and an inline contrast pass says nothing about a color that an email client overrides in dark mode.

## Recommended input

Supply the final HTML artifact produced by the email build, not only a component fragment. Include the document element, head, body, inline styles, layout tables, conditional structures that survive the build, visible copy, and destination URLs. If the provider rewrites or injects markup, inspect a delivered message source as a second pass.

Also supply the text/plain MIME alternative. The plain-text part is not a substitute for accessible HTML and its presence is not, by itself, a WCAG result. It is an important email resilience and preference control. Compare its meaning, required disclosures, and important destinations with the HTML part.

Set the expected message language so the audit can detect a mismatch with the document language. Language tags should be valid BCP 47 values such as en, en-US, fr, or pt-BR.

## Document language

The language of a page enables user agents and assistive technologies to apply appropriate pronunciation, word breaking, glyph selection, and language-specific behavior. The checker inspects the lang attribute on the html element and compares it with the expected language.

A valid root declaration does not address passages written in another language. If a message switches languages, mark the relevant element when the change is meaningful and client support permits it. Brand names, borrowed words, and proper names do not always need a language change.

The parser checks the shape of a language tag, but it does not maintain a complete registry or prove that the chosen value matches the prose. A human reviewer must confirm the actual language.

## Images and alternative-text decisions

Every image needs an explicit decision. That does not mean every image needs descriptive text.

### Meaningful images

When an image communicates information or performs a function, its text alternative should convey the same purpose in the email context. Good alternative text depends on why the image is present, not on a literal inventory of pixels.

For a product image, the product name may be enough when adjacent text supplies the details. For a chart, the important conclusion and values should normally appear in nearby body copy, because a long alt attribute is a poor place for complex data. For a status icon, “Payment received” describes the result better than “green check mark.” For an image of text, the alternative must preserve the information, although real HTML text is usually more adaptable and reliable.

The checker flags missing attributes, filename-looking values, unusually long alternatives, and redundant phrases such as “image of.” Those are heuristics. A reviewer still decides whether the alternative is equivalent in this specific message.

### Decorative images

Pure decoration generally uses an empty alt attribute: alt="". This gives the image an explicit, ignorable alternative-text decision. Omitting the attribute is different; user agents may expose the filename, URL, or an unhelpful placeholder.

Some email templates also use role="presentation" on decorative images, but the empty alt decision remains the central source signal. Verify behavior in the target client and assistive-technology combinations.

### Linked images

A linked image may be the only content that names an action. If its alt attribute is empty and the link has no visible or programmatic label, the destination becomes unnamed. The checker evaluates the link as a whole and can resolve visible text, aria-label, aria-labelledby, explicit label relationships for controls, button values, and nested image alternatives.

Describe the action or destination, not merely the artwork. “View invoice 1042” is more useful than “invoice icon.”

### Animated images

Static HTML cannot establish whether an animated GIF or similar asset flashes, moves for too long, contains essential information in later frames, or offers a way to pause. The checker creates a manual gate whenever it finds a GIF source. Review every frame, timing, repetition, first-frame fallback, and any safety risk. Do not assume that an email client will animate or freeze the same frame everywhere.

## Link names and purpose

Links should communicate their purpose from the link text alone or from the link text together with programmatically determined context. The checker finds links without resolvable names and flags very generic names such as “Click here,” “Here,” “Read more,” or “View.”

Generic text is not automatically a failure in every context, but repeated generic links are difficult to navigate in a screen-reader links list and difficult to distinguish for many readers. Prefer names such as:

- Review the July deliverability report
- Confirm your billing address
- View invoice 1042
- Read the domain authentication guide
- Manage notification preferences

The accessible name and destination should agree. Avoid placing the full raw tracking URL in visible HTML copy; use meaningful text and retain the destination in href. In the plain-text alternative, show usable destinations for important actions.

Links should also be visually identifiable without depending only on subtle color differences. Static source analysis cannot prove the final visual affordance because clients change CSS. Review under normal, hover or focus where supported, visited where relevant, dark-mode, and high-contrast conditions.

## Headings, reading order, and structure

Semantic headings let people understand and navigate sections. Font size, weight, or table layout does not create a heading relationship. The checker identifies h1 through h6 elements, empty headings, and level jumps that deserve outline review.

Heading levels should represent section nesting rather than visual size. A jump is not automatically a failure, and email messages do not need a ceremonial h1 if the structure is very short. The goal is an outline that represents the message.

Source order matters because an email may be linearized when styles, tables, or images are unavailable. Responsive designs sometimes use CSS to rearrange columns visually while leaving a confusing DOM order. Disable CSS and images, read the content in source order, and verify that:

- headings precede the sections they name;
- explanatory text appears before the action that depends on it;
- multi-column content linearizes coherently;
- preheader and hidden utility text do not become disruptive;
- footer disclosures and unsubscribe controls remain understandable;
- duplicated mobile and desktop content is not announced twice.

The checker cannot prove reading order from appearance. This is always a manual test gate.

## Layout tables and data tables

Email HTML often depends on tables for layout. A layout table does not express data relationships, so exposing it as a table can add noisy row and column announcements. When a table exists only for presentation, role="presentation" or role="none" can suppress table semantics in supported environments. Test the received message because support and transformations vary.

A data table is different. It needs preserved table semantics, meaningful header cells, and programmatic relationships. Simple data tables generally use th cells with scope="col" or scope="row". Complex tables may need explicit id and headers relationships, but complexity itself is a reason to consider a simpler presentation in email. A caption can identify the purpose when adjacent context does not already make it clear.

Never add a presentation role to a true data table. Doing so can hide the relationships it needs. The checker treats a table containing th or caption as likely data and flags conflicting presentational semantics.

## Accessible names, ARIA, and robustness

Native HTML semantics are usually more reliable than custom roles. A button element communicates more than a styled div with role="button", although email clients may restrict interactive markup. The checker inspects common interactive elements and role buttons for a resolvable name. It also checks missing aria-labelledby references, duplicate IDs, and positive tabindex values.

ARIA cannot repair an interaction that does not work in the recipient's client. Client sanitization may remove attributes or scripts, and keyboard interaction for custom controls may be absent. Keep critical actions as ordinary links where possible, use clear visible labels, and treat advanced interactivity as progressive enhancement.

Duplicate IDs can break label and table relationships because a reference no longer identifies one unambiguous element. Positive tabindex values override natural focus order and become difficult to maintain. Prefer logical source order.

The checker resolves a useful subset of accessible-name sources. It is not a full implementation of the Accessible Name and Description Computation specification and cannot reproduce every browser, client, or assistive-technology combination.

## Contrast calculations

For normal text, WCAG 2.2 Success Criterion 1.4.3 uses a minimum contrast ratio of 4.5:1. For large-scale text, the minimum is 3:1. Large-scale text is approximately 24 CSS pixels at normal weight or 18.66 CSS pixels when bold, based on the WCAG point-size definitions.

The ratio is derived from relative luminance. For foreground luminance L1 and background luminance L2, where L1 is the lighter value:

    contrast ratio = (L1 + 0.05) / (L2 + 0.05)

The checker parses supported opaque hexadecimal, RGB, and basic named colors from inline style declarations and inherited inline ancestors. It determines the threshold from the inline font size and weight it can resolve. The output preserves the element label, normalized foreground, normalized background, ratio, threshold, large-text classification, and result.

This deliberately narrow calculation avoids pretending that an unknown background is white or that a declared color survives rendering. It does not compute:

- class-based or style-block cascade;
- gradients or background images;
- alpha compositing and transparency;
- colors baked into imagery;
- CSS variables or unsupported color functions;
- client-injected styles;
- forced colors or high-contrast modes;
- dark-mode transformations;
- anti-aliasing or unusually thin glyph behavior;
- non-text contrast for controls and meaningful graphics.

An absent pair is not a pass. It means the parser lacks enough evidence. Render the delivered message in representative clients, identify the computed foreground and actual background, and test normal and dark appearances. Check text over hero imagery at the lowest-contrast location, not only an average sample.

WCAG does not define a universal 14px minimum font size for email. Avoid turning an informal readability preference into a claimed WCAG requirement. Text resizing, reflow, spacing, contrast, legibility, and the needs of the audience still matter.

## Reflow, zoom, and text spacing

The checker flags missing viewport metadata and fixed widths above a practical review threshold, but source width alone does not prove a reflow failure. Email clients use different viewports, scaling rules, CSS support, and clipping behavior.

Test narrow mobile widths and enlarged text. Confirm that content does not clip, controls remain visible, columns linearize coherently, and essential reading does not require scrolling in two dimensions. Increase text spacing where the client allows it and check for overlap or truncation. Do not disable user scaling.

Buttons and links should remain easy to identify and activate. WCAG target-size requirements have details and exceptions, while email-client behavior complicates interaction. Treat target dimensions and spacing as a rendered design review rather than a conclusion inferred from source alone.

## Motion, flashing, and disappearing content

The deprecated marquee and blink elements are direct warning signs and the checker reports them as source failures. Animation in an image or CSS requires a broader test.

Review whether motion starts automatically, lasts longer than the applicable threshold, repeats, can be paused where required, or causes unsafe flashing. Ensure the first frame contains enough information when clients do not animate. Do not put the only deadline, price, code, or call to action in a later frame.

Respect reduced-motion preferences where the delivery environment supports them, but do not rely on support being universal. A stable alternative is the safest baseline.

## Plain-text alternative and final MIME

An HTML editor preview is not the delivered message. The final MIME package may include a subject, preheader behavior, HTML and text alternatives, transfer encodings, attachments, tracking rewrites, unsubscribe headers, provider footers, and authentication-related transformations.

The checker accepts a text/plain alternative so the handoff can record whether it was supplied and whether important URLs appear. Then inspect the actual received message:

1. Confirm that multipart/alternative contains meaningful text and HTML parts.
2. Compare information, required disclosures, dates, amounts, and actions.
3. Confirm important destinations are usable without HTML.
4. Inspect provider-injected content and rewritten links.
5. Test with images blocked and CSS reduced.
6. Verify that hidden preheader techniques do not create repeated or confusing speech.
7. Confirm the subject accurately identifies the message.

The existence of text/plain does not excuse inaccessible HTML. Some recipients prefer or require the HTML experience, and some clients generate a plain view independently.

## Manual test matrix

Complete the static review with a documented matrix appropriate to the audience and risk.

### Clients and rendering modes

- representative webmail, desktop, and mobile clients;
- normal and dark mode;
- images on and off;
- narrow viewport and enlarged text;
- CSS reduced or stripped where practical;
- forwarded or quoted presentation when important.

### Assistive technology and input

- at least one representative screen reader with a supported browser or mail client;
- keyboard-only navigation where the client exposes focusable content;
- links list and heading navigation;
- reading from the top in source order;
- high-contrast or forced-color mode where relevant;
- voice control or magnification when the audience and risk justify it.

Record the operating system, client, version, assistive technology, mode, date, template build, result, evidence, and owner. A bare statement that “screen reader testing passed” is not reproducible.

## Operational workflow

### 1. Define scope

Identify the message type, audience, supported clients, legal or contractual requirements, language variants, and release owner. Accessibility expectations apply to transactional messages as well as marketing campaigns.

### 2. Audit the built source

Paste the complete built HTML and text alternative. Set the expected language. Export JSON as a machine-readable baseline and CSV for a remediation queue.

### 3. Fix deterministic failures

Resolve missing names, broken references, language declarations, empty headings, semantic conflicts, and contrast pairs with sufficient evidence. Re-run the same source.

### 4. Triage warnings

Review each suspicious pattern with context. Mark accepted decisions with an explanation rather than silently deleting them from the workflow.

### 5. Complete manual gates

Send through the real provider to representative accounts. Test reading order, clients, assistive technology, zoom, reflow, dark mode, motion, images, and MIME.

### 6. Preserve evidence

Keep the source artifact, parser export, rendered screenshots where useful, manual-test matrix, known exceptions, owners, and release decision. Re-test when the template, provider, editor, tracking stack, or major client behavior changes.

### 7. Prevent regression

Run deterministic checks in the template build where practical. Do not turn heuristics into unconditional build failures without accounting for context. A strong gate blocks facts and queues judgment.

## Limitations and false positives

HTML email is transformed by build systems, sending providers, security filters, and recipient clients. The DOM parsed in a browser is not a perfect model of any one email client. Some unsupported markup may be dropped; some attributes may be rewritten; conditional comments and vendor-specific structures may not behave as they do in Outlook or other specialized engines.

The tool does not:

- render screenshots or emulate email clients;
- fetch images, stylesheets, fonts, or linked documents;
- upload or send a test message;
- implement every WCAG success criterion;
- implement the complete accessible-name algorithm;
- determine whether prose is understandable;
- judge whether alt text matches an unseen image;
- inspect all animation frames;
- establish legal compliance;
- replace testing by people with disabilities.

Treat every result according to its evidence class. A parser failure may still be a false positive if the supplied source is incomplete. A clean result may still hide a serious rendered failure.

## Export formats

The copyable brief summarizes state, declared and expected language, finding counts, coverage, open remediation, and the manual boundary.

CSV contains one row per finding with severity, category, title, criterion, detail, evidence, and action. It is suited to spreadsheets and issue imports.

JSON contains generation time, model boundaries, scope, summary counts, complete findings, explicit contrast pairs, and the manual test list. It is suited to versioned evidence, scripts, and internal dashboards.

Exports contain portions of the supplied evidence. Review them before sharing because URLs, copy, and identifiers may be sensitive.

## Frequently asked questions

### Can the tool certify WCAG conformance?

No. It provides bounded source evidence and manual test gates. Conformance applies to an experience under defined requirements and cannot be certified by this static parser.

### Does WCAG require 14px email body text?

No. WCAG 2.2 does not define a universal 14px minimum. Font size still affects readability, reflow, target design, and the contrast threshold's large-text classification.

### Does every image need descriptive alt text?

Every image needs an explicit decision. Meaningful images need an equivalent alternative. Pure decoration can use empty alt text so it can be ignored.

### Is empty alt text the same as a missing alt attribute?

No. Empty alt text explicitly indicates that the image contributes no accessible text. A missing attribute can expose an unhelpful filename or source.

### Should email layout tables use role="presentation"?

Usually when they are only layout, subject to client testing. Never suppress semantics on a real data table.

### Why did the checker not test a visible color?

It only calculates supported opaque pairs that can be resolved from inline source and ancestors. Classes, gradients, images, transparency, CSS variables, and client transformations remain manual.

### Are ARIA labels safe in every email client?

Support varies and attributes may be transformed. Prefer meaningful visible text and native semantics, then test the received message in target combinations.

### Is a plain-text MIME part required for WCAG?

The tool does not claim that text/plain is a universal WCAG requirement. It treats the part as an email resilience and recipient-preference control that should preserve important meaning and destinations.

### What should block a release?

At minimum, unresolved deterministic source failures should be corrected or explicitly adjudicated, and required manual tests should be complete for the defined risk and audience. Organizations should set their own documented release policy.

## Primary standards references

- [W3C: How to Meet WCAG 2.2](https://www.w3.org/WAI/WCAG22/quickref/)
- [W3C: Understanding Success Criterion 1.1.1, Non-text Content](https://www.w3.org/WAI/WCAG22/Understanding/non-text-content.html)
- [W3C: Understanding Success Criterion 1.4.3, Contrast Minimum](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html)
- [W3C: Understanding Success Criterion 1.3.1, Info and Relationships](https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html)
- [W3C: Understanding Success Criterion 2.4.4, Link Purpose in Context](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html)
- [W3C: Understanding Success Criterion 3.1.1, Language of Page](https://www.w3.org/WAI/WCAG22/Understanding/language-of-page.html)
- [W3C: Understanding Success Criterion 4.1.2, Name, Role, Value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html)
- [W3C: Understanding Success Criterion 1.4.10, Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html)

## Related Email Bump tools and guidance

- [Email word and structure analyzer](https://emailbump.com/tools/email-word-counter.md)
- [Email signature builder](https://emailbump.com/tools/email-signature-builder.md)
- [Email preheader generator](https://emailbump.com/tools/email-preheader-generator.md)
- [Email spam-language and content-risk checker](https://emailbump.com/tools/spam-trigger-word-checker.md)
- [CAN-SPAM readiness checker](https://emailbump.com/tools/can-spam-readiness-checker.md)
- [List-Unsubscribe header generator](https://emailbump.com/tools/list-unsubscribe-header-generator.md)
- [Email header analyzer](https://emailbump.com/tools/email-header-analyzer.md)
- [Email editor documentation](https://emailbump.com/docs/editor.md)
- [Transactional API documentation](https://emailbump.com/docs/transactional-api.md)