Why is missing image alt text a problem?
When image alt text is missing, people who cannot see the image lose whatever it communicated, and the browser has nothing to show if the file fails to load. This is an accessibility defect first: WCAG 2.2 Success Criterion 1.1.1 requires a text alternative for non-text content. The fix is not to add a filename or the word "image" — it is to describe the image's purpose, or to mark it as decorative when it carries no information.
Why this matters
WCAG 2.2 SC 1.1.1 (Non-text Content, Level A) states that all non-text content presented to the user has a text alternative that serves the equivalent purpose. The criterion carves out decorative content: if non-text content is pure decoration, is used only for visual formatting, or is not presented to users, it must be implemented so assistive technology can ignore it. MDN's guidance on <img> matches this. It says the alt attribute provides a textual replacement, that screen readers read the value aloud, and that an empty value — alt="" — signals the image is not a key part of the content (decoration or a tracking pixel) and may be omitted from rendering; visual browsers also hide the broken-image icon when alt is empty. Getting this wrong is a documented failure: WCAG failure F65 is omitting the alt attribute on images, and F39 is giving a non-null placeholder such as alt="image" or alt="spacer" to an image that should be ignored. There is a modest SEO dimension, but it should not be overstated. MDN notes the alt value is reused when copying an image into text and when saving a linked image to a bookmark, and alt text is what is read when images do not load. Treat search benefits as a side effect of doing accessibility correctly, not as the goal.
How to fix it
For every informative image, write alt text that conveys the same meaning the image conveys, in the context of the surrounding text. Describe the purpose, not the pixels, and avoid repeating "image of" or the filename. For a linked image, describe where the link goes, the way you would for a text link. For a purely decorative image — a spacer, a flourish, a background flourish that is already described nearby — use an empty alt="" so assistive technology skips it; if the image is referenced from CSS as a background, it is already out of the accessibility tree. Never omit the attribute, and never use title as a substitute. MDN shows the contrast plainly: alt="image" is unhelpful because a screen reader may announce "...: image", while alt="A penguin on a beach." reads meaningfully after the same sentence. If an image is a control, such as an icon inside a button, describe the action, for example alt="Search" rather than alt="magnifying glass".
<!-- incorrect: no alt attribute at all (WCAG failure F65) -->
<img src="penguin.jpg">
<!-- incorrect: placeholder / filename, not a description (F30, F39) -->
<img src="penguin.jpg" alt="image">
<img src="penguin.jpg" alt="penguin.jpg">
<!-- correct: informative image, meaning preserved -->
<img src="penguin.jpg" alt="A penguin on a beach.">
<!-- correct: decorative image, ignored by assistive tech -->
<img src="divider.png" alt="">
How to verify the fix
Inspect each image in the browser. In DevTools, select the <img> node and open the Accessibility pane to read the computed accessible name: an informative image should expose a meaningful name, and a decorative image should expose none. You can also view the source or fetch the HTML and scan for <img tags that have no alt attribute at all; those are the definite failures. Remember that JavaScript can insert images after the initial HTML, so check the rendered DOM, not only the static source.
# list image tags in the served HTML and eyeball which lack alt
curl -s https://www.example.com | findstr /I "<img"
# in DevTools: select the <img>, open the Accessibility pane,
# and confirm the computed name matches the alt text.
Automated check
App Readiness Auditor does not inspect images, does not read alt attributes, and does not evaluate WCAG conformance, so it cannot detect image alt text missing from your pages. The closest related checks it runs are structural and metadata checks, such as whether heading structure is consistent and whether the document declares a language — other accessibility-adjacent signals, just not this one.