Advice about alt text is everywhere, and almost none of it tells you what actually reaches the person using a screen reader. You are told to be descriptive, to avoid stuffing keywords, to leave decorative images empty. Fine. But what does the browser really hand over when you write alt="" instead of leaving the attribute off, or when you put a caption under an image and skip the alt entirely?
We stopped guessing and read it directly. Browsers build an accessibility tree, a parallel version of the page containing the role and the accessible name of every element, and that tree is what assistive technology consumes. We took fourteen common markup patterns, put each one in isolation, and asked Chrome what it had produced.
Several results are not what the advice implies.
What we tested, and how
Each pattern was a single image on an otherwise empty page. We queried the accessibility tree through the Chrome DevTools Protocol and recorded two things per image: the role the browser assigned, and the accessible name it computed. The name is the string a screen reader announces. When a node is marked ignored, it is not surfaced at all.
Missing alt and empty alt are opposite instructions
This is the single most consequential result, and it is routinely described as a minor style preference.
An image with alt="" came back with role=none and was marked ignored. It does not exist as far as assistive technology is concerned, which is exactly right for a divider, a decorative flourish or a background texture that carries no information.
An image with no alt attribute at all came back with role=image and an empty name. It is announced, but as an image with nothing to say. Screen readers handle that gap in different ways, and a common fallback is to read out the filename, which is how listeners end up hearing "I M G underscore four zero two one dot J P G" in the middle of a paragraph.
So the two are not degrees of the same thing. alt="" says "skip this, it is decoration". Omitting the attribute says "there is an image here and I have not told you anything about it". Only one of those is ever a deliberate choice.
An unlabeled image inside a link breaks the link
The worst outcome in our tests was not an image that went unread. It was a link that did.
We wrapped an image with no alt in an anchor. The image came back nameless, as expected. But so did the link: role=link, accessible name empty. A person navigating by links, which is one of the fastest ways to move through a page without sight, reaches an interactive element that announces nothing at all. There is no way to know where it goes short of activating it.
Give the same image alt="View your cart" and the link inherits it, announcing as "View your cart, link". The fix costs eleven characters.
The rule this produces is more specific than "describe the image". When an image is the entire content of a link, the alt text should describe the destination, not the picture. A cart icon linking to checkout is not "shopping cart icon", it is "View your cart". You are naming a control, not captioning a photograph.
A caption does not name the image
We put an image inside a <figure> with a clear <figcaption> reading "Sales by quarter", and left the alt attribute off. Plenty of people assume this is covered, because the caption is right there and visibly associated with the image.
It is not covered. The image came back with an empty name. The caption is announced as its own piece of text, but it never becomes the image's accessible name.
That distinction matters because a caption and an alt do different jobs. A caption adds context everyone can see: which quarter, what the source is. Alt text conveys what the image itself shows to someone who cannot see it. On a chart, the caption might say "Sales by quarter" while the alt says "Bar chart, Q3 highest at 42 percent". Only the second one carries the actual information, and in our test that is precisely what the browser exposed when both were present.
title is a fallback, not a substitute
Two related results. An image with a title attribute and no alt was named from the title. An image with both was named from the alt, and the title was ignored for naming purposes.
So title does fill the gap when nothing else is available, but relying on it is a bad idea for reasons that have nothing to do with the accessibility tree: title text only appears on hover, which excludes touch devices entirely, and support for announcing it is inconsistent across screen readers. Treat it as a tooltip that happens to have a fallback behavior, not as a way to label images.
An aria-label, by contrast, named the image reliably. It is a legitimate option, though on a plain <img> there is no reason to reach for it when alt does the same job with less machinery.
Keyword stuffing is read out loud, in full
We tested alt="image photo picture compress resize convert free tool", the kind of string that gets written when alt text is treated as an SEO field. The browser returned it verbatim as the accessible name. Every word of it is announced, in order, in the middle of the page.
It is worth sitting with that for a moment. Stuffed alt text is not a neutral trick that search engines might reward and nobody else notices. It is noise inserted directly into somebody's reading experience, and it makes your page actively worse to listen to.
The redundant-prefix case is milder but the same idea. alt="Image of a red bicycle..." announced the words "Image of" before getting to the content, on an element already announced as an image. The listener hears the word twice. Drop the prefix and start with the subject.
How to write alt text that actually works
The results collapse into a short set of rules.
- Describe the function, not the file. Ask what the image is doing on the page. If it is illustrating a point, describe what a sighted reader would take from it. If it is a link or a button, name the destination or the action.
- Lead with the subject. No "image of", "photo of", "graphic showing". The role already says image.
- Be specific and finite. A sentence is usually plenty. If an image genuinely needs a paragraph, such as a complex chart, put that in the surrounding text where everyone benefits, and keep the alt to the headline finding.
- Charts and screenshots get their conclusion, not their appearance. "Bar chart, Q3 highest at 42 percent" beats "a bar chart with four bars".
- Never leave the attribute off. Every image gets an alt. If it carries no information, it gets
alt="", deliberately. - Do not stuff keywords. If a keyword belongs in an honest description it will appear naturally.
One thing no alt attribute can rescue: text baked into an image. A price, a headline or a quote rendered as pixels is unavailable to screen readers, unselectable, untranslatable and invisible to search engines. Real text over a CSS background is nearly always the better build. When you are handed an image you did not make and cannot rebuild, our image to text tool will pull the wording out so you at least have something accurate to write into the alt.
Decorative images, and inline SVG icons
Decoration is the case where the correct alt text is none at all, and both routes we tested work identically: alt="" and role="presentation" each produced role=none and an ignored node.
Inline SVG icons are the interesting case, because the common advice is to add aria-hidden="true" to every decorative one. We expected to find a problem here and did not. A bare inline <svg> with no title, no aria-label and no role came back as role=none, ignored, exactly the same as one carrying aria-hidden="true". Chrome already treats an unlabeled SVG as decorative.
That does not make aria-hidden pointless. It states the intent explicitly, it protects you if an icon later gains a title element, and behavior is not guaranteed to be identical in every browser and assistive technology combination. But if you have a page full of unlabeled decorative icons, they are not silently shouting at anyone, and that is worth knowing before you spend a day adding attributes.
The one thing that does need attention: an SVG that is meaningful, such as an icon that is the only content of a button, needs a real accessible name via aria-label on the control.
Does any of this help SEO?
Some, and less than the SEO framing suggests. Alt text is how search engines understand what an image depicts, so it genuinely matters for image search and for the context of the surrounding page. That is a real benefit and a good reason to write it well.
What it is not is a ranking lever you can pull by repetition. Stuffing produces a page that is worse for listeners and no better for search. The honest framing is that accessible alt text and useful-for-search alt text are the same text, written once, describing the image accurately. If you want the rest of the image SEO picture, our image SEO guide covers where alt sits relative to the things that move the needle more, which are size and format.
We ran this on our own site
It would be poor form to publish this without checking ourselves, so we ran the same audit across five ImgCruncher pages: the homepage, a tool page, a guide, the tools index and the about page.
Fourteen images in total, every one carrying a descriptive alt, none missing the attribute, none using a filename. The 104 inline SVG icons on the homepage are unlabeled decoration, which the accessibility tree ignores as described above.
We have published our own failures before, in the website image asset audit, so it is only fair to report a clean result the same way. The audit itself took about a minute per page, which is the real point: this is quick to check and there is no good reason not to know.
The short version
Write an alt attribute on every image without exception. Make it empty and deliberate when the image is decoration, and make it describe the destination when the image is a link. Do not expect a caption to do the job, do not rely on title, and do not stuff keywords into a string that a real person has to sit through. Everything above came out of asking the browser directly, and you can ask it the same question about your own pages in a few minutes.
