Writing alt="" (empty quotes) and omitting the alt attribute entirely look almost identical in your HTML editor — but to a screen reader, they mean completely opposite things, and this single, easy-to-miss distinction is one of the most common alt-text mistakes on the web
The previous articles on this site covered alt text basics, writing alt text for SEO/accessibility, image SEO beyond alt text, and the legal landscape around WCAG 1.1.1. This article addresses a specific, frequently-confused distinction: alt="" vs no alt attribute at all — two things that look nearly identical in source code, but produce opposite behaviors for assistive technology.
alt="": "this image is decorative — skip it"
<img src="divider.png" alt=""> — an empty alt attribute (present, but with no text) — is the correct, intentional way to mark an image as purely decorative — carrying no meaningful content that needs to be conveyed to users who can't see the image.
Screen readers, encountering alt="", skip the image entirely — not announcing "image" or any filename/placeholder — the image is, effectively, invisible to screen-reader users, exactly as intended for purely decorative elements (visual dividers, background-style flourishes, icons that duplicate adjacent text — covered in the original alt-text article's discussion of when alt="" is appropriate).
Missing alt attribute: "unknown — announce something, often the filename"
<img src="IMG_4892.jpg"> — no alt attribute at all — is NOT equivalent to alt="".
Screen readers, encountering an image without an alt attribute, vary in behavior — but commonly, they announce something, often including the image's filename/URL — <img src="IMG_4892.jpg"> (no alt) might be announced as something like "image, I-M-G underscore 4892 dot jpg" — which, for a screen-reader user, is meaningless, disruptive noise — conveying no useful information, while still interrupting the reading flow with an announcement.
The practical difference:
alt="" |
no alt attribute |
|
|---|---|---|
| Screen reader behavior | Skips entirely | Often announces filename/URL, or "image" |
| Intended for | Decorative images | (Nothing — this is an error state) |
| Visual appearance in code | alt="" present |
alt absent |
The visual difference in source code — alt="" vs the complete absence of an alt= attribute — is minimal: one extra alt="" substring — easy to overlook when scanning code, and easy to accidentally omit (or, conversely, easy to accidentally include alt="" when alt="meaningful description" was intended, if a templating system substitutes an empty string for a missing/undefined value).
Why this matters: every <img> should have an alt attribute — even if it's empty
The "rule" that's sometimes stated as "all images need alt text" is, more precisely: all <img> elements should have an alt attribute — its value depends on whether the image is meaningful (descriptive text) or decorative (alt="") — but the attribute's presence itself (regardless of value) is what prevents the "announce the filename" fallback behavior.
A page with many <img> tags, none of which have an alt attribute at all (rather than some having meaningful alt text, others having alt="") — would, for a screen-reader user, produce a barrage of filename/URL announcements — one per image — regardless of whether any of those images were "meaningful" or "decorative" — because the absence of the alt attribute itself triggers the fallback behavior, independent of what the image "should" have been categorized as.
Detecting this distinction with automated tools
Most automated accessibility/alt-text-checking tools — including this site's tool — distinguish between alt="" (empty but present) and missing alt (attribute absent entirely) — typically flagging the missing case as an issue (regardless of whether the image "should" be decorative or meaningful — alt="" would be the correct fix for a decorative image that's currently missing alt entirely; meaningful alt text would be the fix for a meaningful image currently missing alt) — while alt="" itself is typically not flagged as an issue (assuming it's applied to genuinely decorative images — though some more sophisticated checks might flag alt="" on images that appear, based on context, to be meaningful — e.g., an <img> that's also the sole content of a link (<a href="..."><img alt="" ...></a>) having alt="" is generally problematic, since the link would then have no accessible name at all).
The "image inside a link" special case
An image that's the sole content of a link — <a href="/products"><img src="shop-icon.png" alt="Shop"></a> — the alt text serves as the link's accessible name — a screen-reader user, navigating to this link, hears the alt text ("Shop") as the link's label.
If alt="" is used here (perhaps because someone, applying the "decorative images get alt=""" rule too literally, without considering the image's role as a link's sole content) — the link becomes inaccessible — a screen-reader user encountering this link would have no way of knowing what it does/where it goes (the link might be announced as just "link," with no further information — or, depending on the href, possibly the URL itself, which is generally less useful than a meaningful label).
For images-as-sole-link-content: the alt text should describe the link's destination/purpose (e.g., alt="Shop", alt="Go to homepage") — not describe the image itself (e.g., not alt="Shopping cart icon", which describes what the image looks like, rather than what clicking the link does) — and certainly not alt="", which would remove the link's accessible name entirely.
How to use the Image Alt Checker on sadiqbd.com
- For every flagged "missing alt" result: determine, for each such image, whether it's decorative (→ add
alt="") or meaningful (→ add descriptivealttext, per the previous alt-text-writing article's guidance) - For images flagged as having
alt="": double-check whether any of these are the sole content of a link —alt=""on a link-wrapped image is generally an error, requiring meaningful, link-purpose-describing alt text instead - Don't conflate "has an alt attribute" with "has useful alt text": a page could, in principle, have
alt=""on every single<img>(technically "passing" a check for "missingaltattribute") while having zero meaningful alt text anywhere — if any of those images were, in fact, meaningful — this would represent a significant accessibility failure, despite "technically" havingaltattributes everywhere — the checker flags missing attributes; whether the present values (includingalt="") are the correct choice, for each specific image, requires human judgment, per the previous writing-alt-text article.
Frequently Asked Questions
Why would a screen reader announce a filename for an image with no alt attribute, instead of just skipping it like alt=""?
This reflects a design choice in how assistive technology handles "unknown" — alt="" is an explicit signal: "this image has been considered, and determined to be decorative — skip it." The absence of alt provides no signal at all — from the screen reader's perspective, it can't distinguish "this image was deliberately left without alt, because it's decorative, and the developer just forgot the empty-string syntax" from "this image might be meaningful, and alt text was simply never written." **Given this ambiguity, announcing something (even if imperfect — a filename) is generally considered less likely to silently hide potentially-meaningful content from the user, compared to silently skipping — even though, in practice, filenames are rarely useful announcements either. Neither behavior is "good" for missing-alt images — which is exactly why "every <img> should have an alt attribute" is the guidance, removing the ambiguity entirely.
Is the Image Alt Checker free? Yes — completely free, no sign-up required.
Try the Image Alt Checker free at sadiqbd.com — find every image with a missing alt attribute, and distinguish decorative (alt="") from meaningful images on any page.
