Writing Alt Text That Works When Images Are Blocked
Alt text in email serves two audiences at once: screen readers and every recipient with images off. Which images need it, what to write, and how to style it so it reads.
On the web, alt text is read by screen readers and rarely seen by anyone else. In email it is also the visible fallback for every recipient whose client blocks images by default — which includes Outlook on Windows out of the box. That dual role changes both what to write and how to style it.
Root Cause: Two Audiences, One Attribute
A screen-reader user hears alt text in place of an image they cannot see. A sighted recipient with images blocked reads it, rendered as text in the space the image would have occupied. The same string serves both, and the two audiences want subtly different things.
The screen-reader user is served by a description of the image's content or function. The sighted reader with images off is served by whatever the image was communicating — which, if the image contained words, means those words.
Where this matters most is that email images frequently carry content rather than decoration. A header image with the message headline baked in, a button rendered as a picture, a table of figures exported as PNG — each of those has meaning that vanishes with the image. Alt text becomes the only carrier for it, which is a much heavier responsibility than it has on a web page where the same words are usually also in the markup.
What to Write, by Image Role
Three roles, three rules.
Informational images — anything carrying words or data. Write out what the image says. A hero with "Your order has shipped" set in it needs alt="Your order has shipped", not alt="Shipping banner". The better answer is usually to make the headline live text and let the image be decorative, but where the image must carry the words, the alt must carry them too.
Functional images — a logo linking home, an icon acting as a button. Describe the destination or action, not the picture. A logo linking to the homepage is alt="Acme home" rather than alt="Acme logo", because what a user needs is where the link goes.
Decorative images — a divider, a background flourish, a spacer. Use an empty alt="", which tells a screen reader to skip the element entirely. Omitting the attribute is not the same thing: with no alt at all, some readers announce the filename, which is worse than silence.
<!-- Informational: the image contains words, so the alt carries them. -->
<img src="https://cdn.example.com/shipped-hero.png" width="600" height="200"
alt="Your order has shipped"
style="display:block;border:0;width:100%;max-width:600px;height:auto;
font-family:Arial,sans-serif;font-size:20px;line-height:28px;
color:#450920;">
<!-- Functional: describe where it goes, not what it looks like. -->
<a href="https://example.com/"><img src="https://cdn.example.com/logo.png"
width="140" height="32" alt="Acme home"
style="display:block;border:0;"></a>
<!-- Decorative: empty alt, so a screen reader skips it entirely.
An omitted attribute would let some readers announce the filename. -->
<img src="https://cdn.example.com/divider.png" width="600" height="1" alt=""
style="display:block;border:0;width:100%;">Styling the Fallback So It Reads
The detail that separates email from the web: alt text inherits the styling on the img element, so an unstyled image renders its fallback in the client's default — usually small, black, in a serif face, against whatever background is behind it.
Styling the img with the font family, size, line height and colour you want the fallback to have costs nothing when the image loads and makes the blocked state legible when it does not. On a dark brand-coloured background this is not cosmetic: unstyled black fallback text on a dark plate is invisible, which turns a blocked image into a blank space rather than a readable sentence.
The width and height attributes matter here too. They reserve the space so the fallback text has a container of the right size; without them, several clients collapse a blocked image to a small icon and the alt text is truncated or hidden entirely.
Variant: What Outlook Does Differently
The Word engine renders alt text in a bordered placeholder box with its own default styling, and it honours some of your declarations but not others. Font family and colour are generally applied; font size is less reliable, and the placeholder border appears regardless.
Two adjustments help. Setting border: 0 on the image reduces the placeholder chrome. And keeping alt text short — under about eight words — avoids the case where the engine truncates it inside a fixed placeholder rather than wrapping. A long informational alt that reads perfectly in Gmail can be cut mid-sentence in Outlook, which is an argument for the words being live text in the first place.
Common Alt Text Mistakes
Four patterns account for most of the alt text that technically exists and does not work.
"Image of" and "Picture of" prefixes waste the listener's attention. A screen reader already announces that the element is an image, so "Image of a parcel" is heard as "image, image of a parcel". Describe the content directly.
Filenames as alt text — alt="hero-v3-final.png" — happen when an export tool populates the attribute automatically. They are worse than an empty alt because they are announced in full and read as noise, and they are trivially detectable in a build check.
The same alt on every image usually means a template loop that renders a list of products or line items with a static alt. Each item needs alt text derived from its own data, or an empty alt where the image is decorative and the item's name is already present as text nearby.
Alt text that duplicates adjacent copy produces a stutter. A hero image with alt="Your order has shipped" immediately above a live text headline reading "Your order has shipped" is heard twice. Where the headline is already text, the image is decorative in the technical sense and should carry an empty alt — the accessible outcome and the less repetitive one are the same.
The pattern behind all four is that alt text is written once, at the moment the image is added, and then never read again by anyone. The remedy is to make reading it part of the review: the audit pass that reads a template top to bottom with every image replaced by its alt catches all four in a single pass, and takes about a minute per template.
Pipeline Integration
Assert the presence of an alt attribute on every image at build time. It is a trivial check, and the failure it catches — a new image added without one — is otherwise invisible until a screen-reader user or an Outlook recipient encounters it.
Presence is mechanical; quality is not. Add a review step to the accessibility audit that reads each alt string in context and asks whether the message still makes sense with every image replaced by its alt text. That reading is the test, and it is the same one that determines whether the message survives image blocking.
Validation and Deployment Checklist
Frequently Asked Questions
Should alt text repeat a headline that is already live text above the image?
No. If the headline is already present as text, repeating it in the alt makes a screen-reader user hear it twice. Describe the image instead, or use an empty alt if it adds nothing — an illustration accompanying a headline is frequently decorative in the technical sense even though it is not decorative in the design sense.
How long should alt text be?
Long enough to carry the meaning, short enough not to truncate — roughly eight words for anything that will render as a visible fallback. Where the content genuinely needs more, that is a strong signal it should be live text rather than an image, which solves the length problem and several others at once.
Does the title attribute help?
Not in email. It produces a tooltip on hover in some desktop clients, which is invisible on mobile and to screen readers, and it is not a fallback for a blocked image. Some clients also ignore it entirely. Put the effort into the alt.
What about images in the plain-text part?
There are none — the text part carries no images, so alt text does not apply. What it should carry is the same information the images conveyed, written as prose. A text part generated automatically from image-heavy HTML is usually close to empty, which is both an accessibility problem and a spam-score problem.
Related
- Email Accessibility Audits — the wider audit this check belongs to
- WCAG Compliance Checklist for Transactional Emails — the checkpoints alt text satisfies
- Reducing Spam Score in Image-Heavy Emails — the same underlying fix from the filtering side
- Email Background Images and VML — why background artwork can never carry information
← Back to Email Accessibility Audits