( Perceivable / WCAG 1.1.1 )
Alt text is a filename or placeholder
What is this issue?
An <img> has a non-empty alt attribute, but the value falls into one of two known-bad patterns: a bare filename fragment (alt="IMG_4471.jpg", alt="chart.png") or a generic placeholder word with no specific content (alt="image", alt="photo", alt="icon"). In both cases, the attribute satisfies the technical requirement that alt be present and non-empty, while providing none of the actual text alternative (a text description that conveys the same information as a non-text element) that alt exists to provide.
This is different from a genuinely empty alt="", which is a deliberate, correct instruction meaning “skip this decorative image.” A placeholder value is neither correctly empty nor meaningfully descriptive; it sits in a gap most basic automated checks don’t catch.
Why does this matter?
A basic accessibility check that only confirms alt is present and non-empty treats alt="image" as a pass. A screen reader user hears “image” read aloud and learns nothing about what’s actually shown: the exact same practical outcome as a missing alt attribute, just disguised as a technical compliance success. This is one of the most common real-world accessibility failures precisely because it slips past checks that stop at “does the attribute exist.”
A product listing with alt="img_2847.jpg" on every photo tells a screen reader user nothing about the product’s color, condition, or angle shown, information a sighted shopper gets instantly from the same image. A content team that bulk-uploads images through a CMS without manually reviewing generated alt text often ships this failure at scale, across hundreds of images, without any single obviously “broken” page to catch in a casual review.
Who is affected?
- Screen reader users: hear a raw filename or a meaningless generic word read aloud in place of an actual description, with no way to recover the missing information without asking someone else or guessing from context.
- Cognitive disabilities: users who rely on alt text as a supporting cue while reading get a stream of meaningless filenames or repeated generic words instead of useful context, adding noise that makes the page harder to follow rather than easier.
What users experience
Priya uses NVDA on Windows to browse a furniture retailer’s catalog. Every product photo has alt text auto-generated by the CMS from the uploaded filename: “sofa-listing-042.jpg,” “sofa-listing-043.jpg.” NVDA reads each one aloud verbatim as she tabs through the grid. She can’t tell a grey sectional from a beige loveseat without opening each individual product page and hoping the description text mentions color and style, turning a quick browse into a slow, page-by-page investigation.
How do I fix it?
Replace the placeholder value with a description of what the image actually communicates, following the same category-based approach used for any missing alt text: informative, decorative, functional, or complex. This works because the fix isn’t really about adding an attribute that’s already there; it’s about writing content that does the job the attribute is supposed to do.
For a genuinely decorative image that was given a placeholder value out of habit rather than because it carries information, the correct fix is alt="", not a better placeholder; decorative images should be marked empty, not described.
Code Examples
<img src="/uploads/img001.jpg" alt="image">
<img src="/hero.png" alt="photo">
<img src="/products/sofa-042.jpg" alt="sofa-042.jpg"><!-- Informative: describe the actual content -->
<img src="/uploads/img001.jpg" alt="Three team members collaborating at a whiteboard">
<!-- Informative: describe what the hero image shows, not that it is a photo -->
<img src="/hero.png" alt="RedFlag dashboard showing 12 accessibility issues on a scanned page">
<!-- Informative: describe the product, not the filename -->
<img src="/products/sofa-042.jpg" alt="Grey three-seat sectional sofa with chaise, shown from the front">Each fix replaces a placeholder that technically satisfied “alt is present” with text that actually satisfies “alt describes the image”: the difference between passing a basic presence check and being usable by the person the attribute exists for.
Common Mistakes
Mistake: “The alt attribute is filled in, so this image is already accessible.” Presence alone isn’t the requirement; the text has to actually describe the image. alt="image" and a missing alt attribute produce nearly identical outcomes for a screen reader user: no useful information, just delivered through a technically-compliant attribute in one case and an error-state fallback in the other.
Mistake: “CMS-generated alt text from the filename is good enough as a starting point.” Filename-derived alt text is worse than no starting point at all, since it looks intentional and can pass a casual review while still conveying nothing. Write alt text based on what the image shows, never auto-generate it from a filename that was never meant to be read aloud.
Mistake: “A generic word like ‘icon’ is fine for small UI images.” Even a small icon usually conveys something specific, such as a warning, a status, or an action, and “icon” describes its category, not its meaning. If the icon is genuinely decorative and adds no information beyond what’s already stated in nearby text, alt="" is correct; if it conveys something on its own, it needs a specific description.
How RedFlag Detects This
Custom automated: RedFlag’s own DOM detector, runs on every scan. RedFlag’s runCustomRules() engine (extension/content.js:522-536) inspects every img[alt] element and checks the alt value against two known-bad patterns: a regex matching generic placeholder words (image, photo, picture, graphic, img, figure, banner, icon) and a regex matching a bare filename pattern (text ending in an extension like .jpg, .png, or .svg). It does not evaluate whether the text is otherwise meaningful, only whether it matches one of these known-bad shapes.
False negative: an alt value that’s inaccurate but doesn’t match either known-bad pattern passes clean: alt="Product" on a photo of an unrelated item conveys almost nothing useful but isn’t caught, since it isn’t a generic placeholder word or a filename. False positive: an image whose accurate, intentionally short alt text happens to exactly match one of the flagged generic words (a UI style guide page literally labelling a sample as alt="Icon") can be flagged even though the value is contextually correct. Manual step: read every flagged alt value in context and confirm whether it genuinely needs replacing or is a rare legitimate exception.
Manual Testing
- Open the page in Chrome or Firefox with NVDA or VoiceOver running.
- Navigate through the page’s images using the screen reader’s image-navigation shortcut (NVDA: Insert+F7, filtered to Graphics; VoiceOver: the Rotor, filtered to Images).
- Listen to each announced
altvalue: it should describe the image’s actual content or purpose, not a filename fragment or a bare generic word like “image” or “photo.” - If an announcement is a filename, a lone generic word with nothing else, or text that clearly doesn’t match the image shown, the check fails.
Related WCAG Success Criteria
1.1.1 Non-text Content: All non-text content must have a text alternative that serves the equivalent purpose. Placeholder or filename alt text fails this criterion in practice even though it technically satisfies “an attribute is present,” since the text alternative it provides doesn’t serve the image’s equivalent purpose.
Related Issues
Image is missing alt text is the base failure this rule builds on: the same missing-information outcome, just with an alt attribute technically present instead of absent.
Alt text is a raw filename covers the closely related failure where a filename-like string is the only label for a form control rather than an image’s alt attribute.
Alt text repeats adjacent visible text covers a different quality failure in the same family: text that’s meaningful and accurate but noisy because it duplicates something already visible nearby.
Decorative image is not hidden from assistive technology covers the opposite mistake: giving a genuinely decorative image any alt text, placeholder or otherwise, instead of correctly marking it alt="".
Image input is missing alt text covers the equivalent naming failure on a form’s image-based submit control.
References
Frequently asked questions
Why does this pass a basic automated alt-text check but still fail here?
A basic check only confirms the alt attribute is present and non-empty. alt="image" satisfies that condition while conveying nothing. RedFlag runs a second, more specific check that looks at the actual text content for known-bad generic words and filename patterns, catching a failure the presence-only check misses.
Is alt="photo" ever an acceptable value?
Almost never as the entire description. It is technically non-empty, which is why plain presence checks miss it, but it tells a screen reader user only that an image exists, not what it shows. Replace it with a description of the actual content, such as who is in the photo or what it depicts.
Does this rule flag alt text that just happens to contain the word "photo" as part of a real description?
It depends on the exact wording, but the intent is to catch alt text that is entirely a generic placeholder word or a bare filename, not to penalize a genuine description that happens to use a related word naturally, such as "Black and white photo of the founding team in 1998."
How is this different from the redundant-alt rule?
They catch different quality problems on the same underlying issue. This rule flags alt text that is meaningless on its own, such as a filename or a generic placeholder word. redflag-redundant-alt flags alt text that is meaningful but unnecessarily repeats text already visible right next to the image.