( Perceivable / WCAG 1.1.1 )

Decorative image is not hidden from assistive technology

MinorLevel AWCAG 1.1.1 — Non-text Content

What is this issue?

An image serves no informational purpose of its own (it’s visual decoration, a divider, a repeated bullet-point icon standing beside text that already names the same thing), but it has no alt="" and no aria-hidden="true" marking it as such. Assistive technology has no way to know the image is decorative unless a developer says so explicitly, so by default it announces the image the same as it would any informative one.

This differs from a missing-alt failure. The image may carry some alt text, or may render through an element type with no alt attribute at all, like an inline SVG or icon-font span; the shared problem is that nothing tells assistive technology to skip it.

Why does this matter?

Every decorative image a screen reader announces is a small tax the user pays before reaching the content they actually came for. On a single image, it’s barely noticeable. On a page with a repeated decorative icon before every list item, or a background flourish appearing a dozen times down a long article, that small tax compounds into a measurably slower, noisier reading experience than a sighted user gets, who perceives the same decoration instantly and unconsciously filters it out.

A blog article using a small decorative star icon before every section heading, with no aria-hidden, makes a screen reader announce “graphic, star icon” before each heading it should otherwise move through cleanly. None of those announcements convey anything a sighted reader relies on (the star is purely visual rhythm), but a screen reader user has to sit through every one of them anyway.

Who is affected?

  • Screen reader users: hear an announcement for every decorative image that conveys nothing, adding up to real friction on pages where the pattern repeats.
  • Cognitive disabilities: users relying on a screen reader to reduce reading load get extra, meaningless audio to filter out, working against the goal of clean, low-friction navigation through content.

What users experience

Grace uses TalkBack on her Android phone to read a recipe blog. Every recipe step has a small decorative checkmark-style icon in front of it, meant purely as a visual list marker with no informational content, and none of the icons are hidden from the accessibility tree. TalkBack announces “icon” before each of the twelve steps in the recipe, on top of the step text itself. She has to filter out twelve redundant announcements just to follow along with a recipe a sighted reader scans in seconds.

How do I fix it?

Give every purely decorative <img> an empty alt="" attribute rather than omitting alt entirely. This works because an empty alt is a deliberate, well-supported instruction that tells every major screen reader to skip the image silently, while a missing alt attribute is an error state that can trigger a fallback announcement of the filename instead: the opposite of what you want for decoration.

For decorative content that isn’t a plain <img> (an inline SVG icon, an icon-font <span>, a CSS-generated background shape wrapped in a semantic element), use aria-hidden="true" instead, since those element types have no alt attribute to set.

Code Examples

Before
<img src="/icons/checkmark.svg">
<span class="icon-star" role="img"></span>
After
<!-- Plain img: empty alt, never a missing attribute -->
<img src="/icons/checkmark.svg" alt="">

<!-- Non-img element: aria-hidden, since there is no alt to set -->
<span class="icon-star" aria-hidden="true"></span>

Both fixes accomplish the same thing through the mechanism each element type actually supports (an empty alt for <img>, aria-hidden for everything else), so the decorative icon disappears from what assistive technology announces while remaining fully visible for sighted users.

Common Mistakes

Mistake: “Leaving alt off entirely is simpler than typing alt="", and both mean ‘decorative’ anyway.” They don’t behave the same way. A missing alt attribute is an error state that many screen readers respond to by announcing the image’s filename as a fallback, often noisier than if the developer had done nothing at all. alt="" is the explicit, correct instruction to skip the image; omitting the attribute is not equivalent to setting it empty.

Mistake: “This icon is small, so it’s not worth the extra attribute.” Size has no bearing on whether an image gets announced: a screen reader doesn’t perceive pixel dimensions, only DOM structure. A tiny repeated icon announced a dozen times down a page adds up to more cumulative noise than one large decorative banner announced once.

Mistake: “If the icon has any visual meaning at all, it must need a real label instead of being hidden.” The test isn’t whether the icon has any visual meaning, but whether that meaning is already available elsewhere for every user. A checkmark icon sitting beside text that already says “Completed” adds no information beyond what the text states; it’s decorative reinforcement, correctly hidden, not an unlabelled informative image.

How RedFlag Detects This

AI-assisted: flagged by the optional Review Labels feature. RedFlag’s label-review workflow (src/lib/ruleCatalogData.js’s LABEL_REVIEW_SEVERITY['decorative-not-hidden']) surfaces a candidate image or icon it suspects is decorative based on context, such as its size, position next to matching text, or repeated use as a list or section marker, and a human reviewer confirms whether it should be hidden. No automated rule in RedFlag’s DOM detector decides “decorative” on its own: the underlying judgment call requires the kind of contextual reading a deterministic script can’t make reliably.

False negative: a decorative image that doesn’t get surfaced as a candidate during a review pass goes unflagged entirely, since detection depends on the AI-assisted workflow running and a reviewer confirming the suggestion. False positive: an image that looks decorative by pattern (small, repeated, positioned near text) but is actually the only place a piece of information appears, such as a status-color icon with no accompanying text label, can be incorrectly suggested for hiding. Manual step: confirm every flagged image genuinely adds no information before hiding it, since hiding a mistakenly-flagged informative image removes real content from screen reader users.

Manual Testing

  1. Open the page in Chrome or Firefox with NVDA or VoiceOver running.
  2. Navigate through the page’s images and icons using the screen reader’s image-navigation shortcut (NVDA: Insert+F7, filtered to Graphics; VoiceOver: the Rotor, filtered to Images).
  3. For each purely visual icon or decoration, confirm it’s silent and skipped, not announced.
  4. If a decorative image announces anything (a filename, a generic word, or a description) and removing it would lose no information a sighted user relies on, the check fails.

1.1.1 Non-text Content: All non-text content must have a text alternative that serves the equivalent purpose; decorative content is explicitly exempt from needing one and should instead be excluded from the accessibility tree. A decorative image that’s announced anyway sits outside a strict 1.1.1 failure, since the criterion doesn’t mandate hiding decoration; this rule is about the practical noise cost, not a compliance gap.

Image is missing alt text covers the opposite mistake on the same attribute: an informative image with no alt at all, rather than a decorative one that’s incorrectly exposed.

Alt text is a filename or placeholder and Alt text repeats adjacent visible text cover other quality failures in the same alt-text family, where the text exists but is meaningless or duplicative rather than the image being wrongly exposed at all.

Object element has no text alternative covers the missing-alternative failure on a different non-text element type.

Focusable element is inside an aria-hidden container covers the inverse mismatch: content hidden from assistive technology that shouldn’t be, rather than exposed content that should be hidden.

References

Frequently asked questions

Is a decorative image that gets announced a WCAG failure?

Technically no, if it has some alt text rather than missing alt entirely. 1.1.1 does not require decorative images to be hidden, only that non-decorative ones have a text alternative. RedFlag surfaces this as a best-practice, informational finding rather than a hard compliance violation, since the practical cost is noise, not missing information.

Should I use alt="" or aria-hidden="true" to hide a decorative image?

For a plain img element, use alt="". It is the standard, well-supported way to mark an image decorative and works identically to aria-hidden in every modern screen reader. Reach for aria-hidden="true" for non-img elements, such as a decorative SVG or an icon-font span, which have no alt attribute to set.

How do I decide if an image is decorative in the first place?

Ask whether removing the image would lose any information a sighted user relies on. If the surrounding text already conveys everything the image shows, or the image is purely visual polish like a divider or background flourish, it is decorative. If it is the only place specific information appears, it is informative and needs real alt text instead.

Does role="presentation" do the same thing as alt=""?

On its own, no. role="presentation" removes the image's implicit image role from the accessibility tree, but on an img element it still needs to be paired with alt="" for consistent behavior across screen readers. alt="" alone is simpler and sufficient for a plain img.