Order Confirmation and Shipping Emails: The Accessibility Gap After Checkout
A shopper who just navigated an accessible checkout with a screen reader gets the same transactional email as everyone else the moment the order goes through — a confirmation, then a shipping notice, then a delivery notice. Those emails are still HTML, rendered by a mail client instead of a browser, and read by the same VoiceOver, NVDA, or JAWS session the shopper was already using. They’re also almost never checked. Our own order-tracking status-update article draws the line explicitly: it covers the tracking page, not the email that told the shopper to go looking for it. This one covers what’s on the other side of that line.
Quick answer: five things break most often. Product thumbnails, shipping-carrier logos, and
status-badge icons need real alt text (SC 1.1.1 Non-text
Content, Level A) — and it
matters more in email than on your site, because whether an image even downloads varies by mail
client, not by a setting the recipient controls per message. A “Thank You for Your Order!” banner
built as a single graphic instead of live text fails SC 1.4.5 Images of
Text (Level AA). “Track Your
Package” buttons need enough contrast against your brand color, not just your logo’s (SC 1.4.3
Contrast (Minimum), Level AA).
The nested <table> layouts most email templates still rely on need role="presentation" so a
screen reader doesn’t announce meaningless row-and-column structure (SC 1.3.1 Info and
Relationships, Level A).
And every link needs to say where it goes, not just “Click Here” (SC 2.4.4 Link Purpose (In
Context), Level A).
This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.1 AA requires for HTML content and how the same principles apply to transactional email, not whether a specific email program carries legal risk.
Why alt text matters more in an inbox than on a page
On your website, whether a visitor sees images is mostly a stable, per-browser setting — someone who’s chosen to block images has usually done it once, everywhere. Email doesn’t work that way. Google’s own help page on Gmail states Gmail’s default plainly: “By default, when you get an email with an image, you’ll see the image automatically” (Gmail does withhold images if it judges a specific sender or message suspicious). Microsoft’s support page for classic Outlook says the opposite is true there: “Microsoft Outlook is configured by default to block automatic picture downloads from the Internet” — for reasons the page lists explicitly, including avoiding “malicious code,” giving the recipient control “especially if you’re on a low-bandwidth connection,” and blocking “tracking pixels: invisible images that can tell a sender you’ve read the email.”
That split matters for how you should think about alt text. On a website, an alt attribute is a
fallback for assistive technology when the visual image doesn’t communicate the same thing. In an
Outlook inbox with default settings, alt text is the entire first impression of every image in
your email — the product photo, the “Shipped” badge, the carrier logo — until the recipient
manually chooses to download pictures. SC 1.1.1’s core
requirement is that “all
non-text content that is presented to the user has a text alternative that serves the equivalent
purpose” — write your order-confirmation alt text as if the image will not load for a meaningful
share of recipients, because for some of them, by design, it won’t.
A graphic “Thank You” banner isn’t a heading
Plenty of order-confirmation templates open with a wide, styled graphic — “Thank You for Your Order!” set in a custom display font, baked into a single image file, sometimes with the order number stamped into the graphic itself. That’s a double failure. First, in an image-blocked inbox (Outlook, by default) it renders as nothing but alt text or a broken-image icon exactly where the most important line of the email should be. Second, even where the image does load, SC 1.4.5 Images of Text exists because, per its own Intent, a person who needs a specific visual presentation — larger size, a different font, a color that isn’t washed out by their device’s brightness or their own low vision — “can adjust the text presentation as needed” only when it’s real text. A graphic banner can’t be resized or restyled by the reader at all. Set the greeting and order number in live HTML text styled with CSS; save the graphic treatment for genuinely decorative art that doesn’t carry the message on its own.
Your CTA button’s contrast doesn’t get a pass because it matches your brand
“Track Your Package” or “View Your Order” buttons are usually styled to match brand color — which is exactly where contrast problems creep in, especially with a lighter or more pastel brand palette. SC 1.4.3’s normative text requires “a contrast ratio of at least 4.5:1” between text and its background, dropping to 3:1 only for “large-scale text” (roughly 18pt, or 14pt bold). White text on a soft mint, light gold, or pale blue button routinely lands well under 4.5:1. Run your actual button colors through a contrast checker the same way you’d check a webpage button — brand consistency and WCAG compliance aren’t the same test, and an email template inherits whatever ratio your design system shipped with, good or bad.
Layout tables still run most email templates — tell screen readers so
CSS support is inconsistent enough across mail clients that most email-builder tools (Shopify,
Klaviyo, Mailchimp, and hand-coded templates alike) still lay pages out with nested HTML
<table> elements rather than modern CSS layout — a workaround for the client, not a real data
table. The problem: a <table> with no further markup is a data table as far as a screen reader
is concerned, and SC 1.3.1
exists precisely because “structure and relationships conveyed through presentation” — rows,
columns, headers — need to match what’s actually there, not announce structure that isn’t
meaningful. MDN’s reference on the ARIA presentation/none role
spells out the fix directly: applying presentation or none to a <table> “removes the default
semantics of the element… and their required descendant elements” — the <tr>, <td>, and
similar children stop being announced as table structure — while, importantly, “elements inside of
the <th> and <td> elements… are exposed to assistive technologies” as normal, so nothing
inside the layout is hidden, only the false table framing around it.
<table role="presentation" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td>Your order #10482 has shipped.</td>
</tr>
</table>If a table in your email genuinely presents tabular data — an itemized list of products with
quantities and line totals, for instance — leave it as a real table with <th> headers; the fix
above is specifically for tables used only to position content on the page.
Link text: “Track Your Package,” not “Click Here,” every time
A shipping email commonly carries more than one link — a primary “Track Your Package” button plus a smaller “View order details” or “Manage subscription” text link further down. SC 2.4.4’s Intent explains exactly why generic link text is a problem: “Assistive technology has the ability to provide users with a list of links that are on the web page. Link text that is as meaningful as possible will aid users who want to choose from this list” — the same mechanism works inside an HTML email. Two buttons both reading “Click Here” are indistinguishable in that list; “Track Your Package” and “Manage Your Subscription” aren’t.
Where to start
In rough order of effort: write real alt text for every product photo, badge, and logo, written as
if it’s the only thing that will render; convert graphic “Thank You” headers to live HTML text;
check your CTA button’s actual contrast ratio, not just its brand-book color; add
role="presentation" to layout-only tables; and give every link and button text that names its
destination.
FAQ
We use Shopify’s or Klaviyo’s default transactional email templates — are we covered automatically? Not necessarily. Default templates vary by platform and theme, and many still use graphic headers or unlabeled images out of the box. Check your actual rendered email the same way this article does, rather than assuming a major platform’s default is accessible by definition.
Does this apply to a PDF invoice attached to the order-confirmation email? The email’s HTML and an attached PDF are two separate documents with separate rules. See our PDF accessibility for e-commerce documents article for what an accessible invoice PDF requires.
Do I need to test in every email client separately? You don’t need exhaustive coverage of every client to catch the failures in this article — alt text, contrast, layout-table markup, and link text are all checkable directly in the HTML before you ever send a test message. Client-by-client visual QA (Litmus, Email on Acid, or manually sending to test accounts) is a separate, useful practice, but it’s a rendering check, not a substitute for getting the underlying markup right first.
Get your full customer journey checked, not just the storefront
Quietramp’s $890 audits focus on your website, not your email platform — but the same WCAG 2.1 AA principles in this article apply anywhere HTML ships, and an accessible checkout followed by an inaccessible confirmation email is still an incomplete accessibility effort. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.
This is educational content about technical accessibility practice, not legal advice. Meeting WCAG 2.1 AA does not guarantee legal compliance with the ADA or any other law, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.
Quietramp is an AI-operated agency with human oversight — this article was drafted by our Content/SEO writer role.