Distinguishing Decorative from Informative Images
AI generated
A11Y
WCAG
Accessibility · Images · Alt Text · WCAG
Distinguishing Decorative from Informative Images
the practical test for alt text, aria-hidden and CSS background images

Screen reader users lose no information when a purely decorative image is missing, but they lose important context when an informative image has no alt text. This article shows a practical test for telling the two apart, correct techniques like empty alt, CSS background images and aria-hidden, and common mistakes when handling icons and decorative graphics in Magento and Hyvä stores.

13 min read WCAG 1.1.1 · alt="" · aria-hidden HTML · CSS · Hyvä Theme

1. Why this distinction determines accessibility

Distinguishing between decorative and informative images is one of the most fundamental, yet most frequently mishandled, decisions in web accessibility. Under WCAG 2.1 success criterion 1.1.1 (Non-text Content), every image that conveys information needs a text alternative, while purely decorative images should be deliberately removed from the accessibility tree so that screen reader users are not bothered with meaningless announcements like "image, blue right arrow icon". Both mistakes cost users time and trust: missing alt text on informative images leaves screen reader users in the dark, while superfluous alt text on decorative icons clutters navigation with noise.

In practice, developers tend to add too much alt text rather than too little, because blanket rules like "every image needs an alt attribute" get misunderstood without the addendum "but not necessarily descriptive content". A divider icon in front of a product category, a decorative pattern in a page background, or a purely illustrative photo next to an already complete paragraph of text are classic candidates for an empty alt attribute, not an image description.

2. The practical test: informative or decorative?

The most reliable practical test is: what happens if I remove this image entirely, does the page lose information or function as a result? If the answer is no, because the surrounding text, the heading, or an adjacent label already conveys the same information, the image is decorative and gets an empty alt attribute. If the answer is yes, because the image shows something that appears nowhere else on the page, such as a diagram, a product photo without a text description, or an icon that is the sole element signaling an action, it is informative and needs a matching text alternative.

A second helpful test for interactive elements: would a sighted user click the image to accomplish something? A magnifying glass icon inside a labeled search button is decorative, because the visible text "Search" already describes the function. A magnifying glass icon as the only content of a button with no visible text, however, is functionally informative and needs either an aria-label on the button or a hidden text, because otherwise no screen reader user learns what the button does. This test works reliably for nearly every edge case.

3. Correctly hiding decorative images: alt=""

An empty alt attribute (alt="") is not a bug and not a forgotten description, it is the correct, semantically deliberate technique for removing an image from the accessibility tree. The crucial difference from a completely missing alt attribute: without an alt attribute, some screen readers announce the file name or the full image path instead, such as "hero-banner-final-v3.jpg", which is completely worthless and disruptive for users. With alt="", the screen reader silently skips the image, exactly the way a sighted user unconsciously ignores a decorative element.

It is important that the alt attribute must still be present in the markup, even when it is empty. If it is missing entirely, many auditing tools and screen readers treat the image as incorrectly marked up, not as deliberately decorative. In Hyvä templates, this rule can be anchored directly in blocks and components, so that decorative images from the CMS or from recurring layout elements are consistently delivered with an empty alt, without editors having to remember it every time.


<!-- WRONG: missing alt attribute, screen reader announces the file path -->
<img src="/media/wysiwyg/divider-line.png">

<!-- WRONG: decorative icon gets an unnecessary description -->
<img src="/media/icons/arrow-right.svg" alt="Blue right arrow icon">

<!-- RIGHT: decorative image deliberately removed from the accessibility tree -->
<img src="/media/wysiwyg/divider-line.png" alt="" role="presentation">

<!-- RIGHT: informative image with a precise, context-aware alt text -->
<img
    src="/media/catalog/product/sneaker-red-side.jpg"
    alt="Red running shoe, model Runner Pro, side view"
    width="600"
    height="600"
>

4. CSS background images instead of img for pure decoration

For images that serve purely visual styling, such as pattern backgrounds, decorative dividers, corner ornaments, or texture overlays, a CSS background image is often the cleaner solution compared to an <img> element with an empty alt. CSS background images are fundamentally not considered by screen readers in the accessibility tree, because they are technically not content but pure presentation. This removes the question of the correct alt attribute entirely, because the question never arises in the first place.

Switching from <img> to background-image is only correct, however, when the image genuinely carries no information that is not also present as text. Hiding a product image as a CSS background purely to avoid writing alt text is an antipattern, because it makes information completely inaccessible to screen reader users while sighted users can still see it. Rule of thumb: only genuine decoration belongs in CSS, every piece of information belongs in semantic markup.


/* RIGHT: purely decorative texture, CSS only, no img tag needed */
.category-header {
  background-image: url("/media/wysiwyg/texture-subtle.png");
  background-repeat: repeat;
  background-position: top left;
}

/* RIGHT: decorative divider element between two sections */
.section-divider {
  background-image: url("/media/wysiwyg/divider-ornament.svg");
  background-repeat: no-repeat;
  background-position: center;
  height: 24px;
}

/* WRONG: product image hidden as a CSS background loses information entirely */
.product-teaser {
  background-image: url("/media/catalog/product/sneaker-red.jpg");
  /* Screen reader users never learn which product is shown */
}

5. Using aria-hidden and role="presentation" deliberately

aria-hidden="true" removes an element from the accessibility tree, regardless of whether it stays visually visible. This is the right tool for icon fonts and inline SVGs that sit next to an already present text label, such as a cart icon directly next to the visible word "Cart" in the header navigation. Without aria-hidden, a screen reader might, depending on the SVG structure, read out the SVG's own title or description text, duplicating or confusing the label.

role="presentation" serves a similar purpose but acts on the semantic role level rather than the visibility level, and it is particularly suited for <img> elements and tables used purely for layout purposes. For icon-only buttons, that is, buttons without visible text, the combination is decisive: the SVG icon gets aria-hidden="true", because it is purely decorative inside the button, while the button itself supplies the missing visible text via aria-label. If only one of the two is set, the button either remains silent or ends up double-labeled.


<!-- RIGHT: icon next to an existing text label, SVG is purely decorative -->
<a href="/checkout/cart" class="flex items-center gap-2">
    <svg aria-hidden="true" focusable="false" class="w-5 h-5">
        <use href="#icon-cart"></use>
    </svg>
    <span>Cart</span>
</a>

<!-- RIGHT: icon-only button, label comes exclusively from aria-label -->
<button type="button" aria-label="Open search" class="p-2">
    <svg aria-hidden="true" focusable="false" class="w-5 h-5">
        <use href="#icon-search"></use>
    </svg>
</button>

<!-- WRONG: neither aria-hidden on the icon nor aria-label on the button -->
<button type="button" class="p-2">
    <svg class="w-5 h-5"><use href="#icon-search"></use></svg>
</button>

6. Informative images: writing good alt text

Once an image is classified as informative, the quality of the alt text determines whether screen reader users receive the same information as sighted users. Good alt text describes the purpose of the image in its specific context, not every visual detail. "Photo" or "Image of" at the start is redundant, because the screen reader already announces the element as an image. For product images, the information relevant to a purchase decision belongs in the alt text: model name, color, view, not the exact pixel arrangement or lighting in the photo.

A common mistake is redundant alt text that repeats content already present as visible text next to the image, such as an alt text "Red running shoe Runner Pro" placed directly next to a product heading "Red running shoe Runner Pro". In this case, the image is redundant to the text from an informational standpoint and could technically even receive an empty alt, provided the image itself carries no additional visual information such as a particular perspective. Alt text length should be guided by information density, not a fixed character count, though roughly 80 to 125 characters is common.

7. Icons in buttons and links: when does an icon need a name?

Icons inside buttons and links are the most common source of error when distinguishing decorative from informative, because the same SVG file can take on either role depending on context. If a visible text like "Add to cart" already sits next to the icon, the icon is pure garnish and gets aria-hidden="true". If the icon is the only content of the interactive element, such as a heart icon for saving a product with no visible text, it functionally takes on the role of the label, and the button must have an aria-label, ideally one that changes with state.

For state-dependent icons, such as a wishlist heart that toggles between "saved" and "not saved", the aria-label must also change dynamically, otherwise the screen reader user is left unaware of the current state while sighted users immediately notice the icon's color change. In Hyvä themes with Alpine.js, this can be solved directly through a reactive x-bind:aria-label binding that updates in sync with the visual state, instead of maintaining the label separately and error-prone.


// Accessible wishlist button: aria-label follows the visual state
function toggleWishlist(button) {
  const isSaved = button.getAttribute('aria-pressed') === 'true';
  const nextState = !isSaved;

  button.setAttribute('aria-pressed', String(nextState));
  button.setAttribute(
    'aria-label',
    nextState ? 'Remove from wishlist' : 'Add to wishlist'
  );

  // The icon itself stays aria-hidden, only the button carries the information
  button.querySelector('svg').setAttribute('aria-hidden', 'true');
}

document.querySelectorAll('[data-wishlist-toggle]').forEach((button) => {
  button.addEventListener('click', () => toggleWishlist(button));
});

8. Complex images: diagrams, infographics and charts

Complex images such as diagrams, infographics, or schematics cannot be fully described in a short alt attribute without the text becoming impractically long. The established solution is a short, concise alt text that summarizes the purpose of the image, combined with a detailed description in the visible text flow directly next to or below the image, for example as a caption inside a <figure> element with <figcaption>. The longdesc attribute is now considered deprecated and is no longer reliably supported by most modern screen readers.

For data visualizations such as bar charts or revenue statistics, the most robust solution is an additional data table, visually hidden from sighted users, carrying the same information, for example via the CSS class sr-only. This gives screen reader users structured access to exactly the same figures, instead of relying on a rough summary. aria-describedby can additionally point to a longer description text when it cannot sit directly in the visible text flow for space reasons.

9. Image types and testing side by side

The following overview summarizes the key decision rules between decorative and informative images and shows which technique is correct for which case. Automated testing with axe-core or Lighthouse catches a large share of errors before deployment, such as missing alt attributes or suspiciously long alt text on presumably decorative icons, but it does not replace manual testing with a real screen reader like NVDA or VoiceOver, because only a human can judge whether an alt text is genuinely meaningful.


{
  "rules": {
    "image-alt": { "enabled": true },
    "aria-hidden-body": { "enabled": true },
    "svg-img-alt": { "enabled": true },
    "aria-input-field-name": { "enabled": true }
  },
  "reporter": "v2",
  "resultTypes": ["violations", "incomplete"],
  "runOnly": {
    "type": "tag",
    "values": ["wcag2a", "wcag2aa", "wcag21a"]
  }
}
Image type Wrong Right Reason
Decorative divider alt="Blue divider line" alt="" No information lost on removal
Icon next to a text label aria-label on icon AND text next to it aria-hidden="true" on the SVG Avoids duplicate announcement
Icon-only button No label anywhere aria-label on button, aria-hidden on icon Button stays operable via screen reader
Purely decorative texture img with alt="" plus an HTTP request CSS background-image No accessibility tree entry needed
Complex diagram Only a short alt text, no detail Short alt text plus figcaption or sr-only table Full information accessible

In practice, these decisions are often connected: anyone applying the removal test consistently arrives almost automatically at the right choice between alt="", CSS background, and detailed alt text for icons, background images, and complex graphics alike. Automated tools reliably catch the structural mistakes, but the content-level polish still requires a human with screen reader experience.

Mironsoft

Accessible images and WCAG-compliant Hyvä implementation

Alt text that actually helps?

We audit existing Magento and Hyvä stores for missing, superfluous, or redundant alt text, fix decorative icons with aria-hidden and CSS background images, and write precise descriptions for genuinely informative images.

Image audit

Systematic review of every image for correct alt assignment

Refactoring

Correctly applying aria-hidden, role="presentation" and CSS backgrounds

Editorial guidelines

Embedding alt text rules into your CMS and product data workflows

10. Summary

Distinguishing decorative from informative images solves a simple but far-reaching problem: screen reader users should receive exactly the information sighted users get from an image, no more and no less. The removal test, what happens if this image disappears entirely, provides a clear answer in almost every edge case. Decorative images should be removed from the accessibility tree with an empty alt attribute, a CSS background, or aria-hidden. Informative images need precise, context-aware alt text that describes the purpose of the image, not every visual detail.

The biggest lever lies in applying this rule consistently across every image type in a store, from product photos to CMS banners to icon-only buttons in navigation. Automated testing with axe-core or Lighthouse reliably finds missing or suspicious alt attributes, but it does not replace manual testing with a real screen reader, because only a human can judge whether an alt text is genuinely meaningful.

Decorative vs. Informative Images: The Essentials at a Glance

The removal test

If removing the image loses information or function, it is informative. Otherwise it is decorative.

alt="" instead of missing alt

An empty alt attribute deliberately hides decorative images. A missing alt attribute counts as an error.

CSS instead of img

Purely decorative textures and dividers belong as background-image in CSS, not in the markup.

aria-hidden on icons

Icons next to text labels get aria-hidden. Icon-only buttons additionally need aria-label.

11. FAQ: Decorative vs. Informative Images

1What is the difference between a decorative and an informative image?
Informative images convey content that appears nowhere else on the page. Decorative images serve only visual styling with no additional information.
2How do I find out whether an image is decorative or informative?
With the removal test: if mentally removing the image loses information, it is informative. Otherwise decorative and gets alt="".
3Why is an empty alt attribute not the same as a missing alt attribute?
An empty alt silently skips the image. If the attribute is missing, some screen readers announce the file name instead, which is disruptive.
4When should I use a CSS background instead of an img tag?
For purely decorative textures, dividers, and patterns. CSS background images are fundamentally not considered by screen readers.
5What exactly does the aria-hidden attribute with the value true do?
Removes an element from the accessibility tree, regardless of visual visibility. Ideal for decorative icons next to text labels.
6Do icon-only buttons really always need an aria-label?
Yes, the icon functionally takes on the role of the label. Without an aria-label the button stays silent for screen reader users.
7How do I write good alt text for product images?
State model name, color, and view. Words like Photo or Image of at the start are redundant since the screen reader already announces the element as an image.
8What do I do with complex images like diagrams?
Short alt text for the purpose, detailed description as a figcaption or sr-only data table right next to the image.
9Which tools check alt text automatically?
axe-core and Lighthouse reliably find missing or suspicious alt attributes and can be integrated into CI pipelines.
10Is automated testing with axe or Lighthouse enough on its own?
No, it catches structural errors but not content quality. Manual testing with a real screen reader remains necessary.