Accessible Icons and Images

The plain-language idea

Every image or icon in an interface falls into one of two categories, and the correct markup depends entirely on which one it is.

A decorative image contributes nothing informational — a background flourish, a redundant icon sitting right next to text that already says the same thing. It should be explicitly marked so assistive technology skips it silently: alt="" on an <img> (an empty string, deliberately set — not a missing alt attribute, which is a different, worse problem some screen readers handle by announcing the image's filename instead), or aria-hidden="true" on a decorative icon element that isn't an <img>.

An informative image conveys something a user needs — it needs real, specific alt text describing what it means in context. Not a lazy alt="image", not the filename, and not an exhaustive visual description of every detail that isn't relevant to why the image is there. Good alt text describes the image's function or meaning, not its full visual content — a photo used as a "delete this profile picture" button's icon should have alt text describing the action, not a description of what's in the photo.

See it in a real thing: the icon-only button

<!-- Broken: no accessible name for the button at all -->
<button>
  <svg><path d="..." /></svg>
</button>

<!-- Fixed: aria-label supplies the missing accessible name -->
<button aria-label="Delete conversation">
  <svg role="img" aria-hidden="true"><path d="..." /></svg>
</button>

A button holding only an SVG icon — a trash can, no visible text — has no text content for a screen reader to read as its accessible name, so by default it announces as an unlabeled, empty button. This connects directly back to how accessible names are computed generally: an element's accessible name comes from its text content, aria-label, or a labelling relationship, and an icon-only button has none of the first unless it's given one of the other two. aria-label="Delete conversation" on the <button> is the direct fix, giving the control a real accessible name independent of what's visually inside it.

What people usually miss

Watch out

• A missing alt attribute and alt="" are not the same thing. Missing alt is flagged as an accessibility error and some screen readers fall back to announcing the filename; alt="" is a deliberate, explicit "skip this" signal that only works when actually present.
• Alt text should describe function and meaning, not exhaustively describe visuals. A chart's alt text should communicate its takeaway ("Revenue grew 40% year over year"), not attempt to describe every bar and axis label — that level of visual detail belongs in surrounding text or a data table, not squeezed into one alt attribute.
• A redundant icon next to text that already says the same thing should be decorative, not double-labeled. A "Delete" text button with a trash icon next to it doesn't need the icon to also carry alt text — that produces a screen reader hearing "trash icon, Delete" for one action.
• Inline SVG needs its own accessible-name mechanism (role="img" plus aria-label or <title>) — simply having a <path> with meaningful visual content doesn't make an SVG announce anything on its own.
• aria-hidden="true" removes an element from the accessibility tree entirely, including from focus-based navigation in some cases — it should never be applied to something a keyboard or screen reader user actually needs to interact with, only to genuinely decorative content.

Why this matters in interviews

"This icon-only button has no visible label — how do you fix it for screen reader users?" is a real, common question, and naming aria-label specifically (plus explaining why the icon-only case has no other source for an accessible name) is the concrete answer interviewers are listening for.