Accessible Icons: aria-hidden, Labels and Icon Buttons

An icon can be perfectly recognizable to its designer and still fail as an interface. A magnifying glass might mean search, zoom, or inspect. A screen reader cannot infer any of these meanings from a path. Accessible icon work starts by deciding what the graphic contributes, then expressing that contribution through the surrounding interface.

Classify the icon before adding attributes

Sort each instance into one of three roles: decorative, informative, or interactive. The same downloaded asset can serve all three. A trash can beside the word Delete is usually decorative. A warning triangle communicating a problem without accompanying text is informative. A trash can inside a button belongs to an interactive control whose action needs a name.

Use the contrast checker during this inventory: enter the icon foreground and its actual background, then compare relevant states. It helps identify weak boundaries and faint strokes, but it cannot tell you whether the icon's meaning is understandable. Evaluate those separately.

Write a small inventory with the icon, context, intended meaning, visible label, and accessible name. This catches reused symbols whose meaning changes between screens. Context determines semantics, not the filename or the icon library's component name. For broader interface requirements, use the accessible interface guide alongside this icon-focused workflow.

Hide graphics that repeat visible words

When text already communicates the complete meaning, hide the SVG from assistive technology. Otherwise, users may hear an unnecessary graphic announcement or a duplicated label before reaching the actual control. Keep the meaningful text visible and available to everyone.

<button type="button">
<svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
  <path d="M5 12h14M12 5v14" fill="none" stroke="currentColor" />
</svg>
Add project
</button>

Here the button receives its name from Add project. The SVG contributes appearance only. The explicit focusable attribute is a defensive compatibility measure; the SVG should not become a second keyboard stop. Do not add a separate tabindex to decorative artwork.

aria-hidden removes accessibility exposure, not visual display. It does not disable a control or reliably prevent keyboard focus. Never put it on the button itself or on an ancestor containing usable controls. The MDN aria-hidden reference explains the distinction and inherited effects.

For decorative graphics loaded through an image element, use an empty alt attribute rather than omitting alt. Avoid adding a title such as Plus icon to every SVG: the geometric description adds noise when the visible words already explain the action.

Name icon-only controls at the control level

An icon-only button needs a name describing its action, not its appearance. Use Search rather than Magnifying glass, and Delete invoice rather than Trash. Prefer visible labels whenever ambiguity or consequence is high; a familiar-looking symbol is not a substitute for understanding.

<button type="button" aria-label="Search invoices">
<svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
  <circle cx="10" cy="10" r="6" fill="none" stroke="currentColor" />
  <path d="m15 15 5 5" stroke="currentColor" />
</svg>
</button>

Put the name on the native button, and hide the nested artwork. This establishes one control, one name. Do not rely solely on a hover tooltip or an SVG title for the button's name. Tooltips may supplement an accessible label, but touch users and keyboard users still need a reliable interface.

If a visible label exists elsewhere, aria-labelledby can reference it. Avoid unnecessary aria-label attributes on already labeled buttons because they can replace useful visible wording. Keep the visible words within the accessible name so speech-input users can invoke what they see.

For toggle controls, express the state as well as the name. A Mute microphone toggle can retain that name while aria-pressed changes. Alternatively, an action button may change between Mute microphone and Unmute microphone without using pressed semantics. Choose a coherent pattern; the WAI button pattern describes expected behavior.

Give informative icons a text equivalent

Some icons carry information rather than an action: a synchronization failure beside a file, an availability badge, or an alert marker. Meaningful status needs text, preferably visible text, because unfamiliar symbols also confuse sighted users.

When the icon is the only visual expression of a short status, an image with appropriate alt text can work. Inline SVG can use role="img" and aria-labelledby referencing a unique title element. Ensure repeated components do not generate duplicate IDs. A reusable component should receive or generate an instance-specific identifier rather than hardcoding status-title across the page.

For a complex illustration, a short accessible name may not communicate all the information. Provide the useful explanation in nearby text instead of packing a paragraph into a title. The WAI images tutorial offers a practical decision framework for decorative and informative graphics.

Do not label every tiny mark inside a combined illustration. Describe the whole message at the appropriate level. Likewise, a colored status dot should not be announced as Green circle when the useful message is Available. Use redundant cues such as words and shape, not color alone.

Check size, contrast and actual behavior

A 16-pixel icon can live inside a much larger clickable button. Separate the visual glyph from its interaction target. As a working design preference, aim around 44 by 44 CSS pixels for comfortable controls where space allows, while checking the actual WCAG target-size requirements and exceptions for your interface.

Essential graphical objects and visual information needed to identify controls generally require 3:1 contrast against adjacent colors under WCAG non-text contrast. Decorative graphics and inactive controls have different treatment. Check the meaningful stroke, not just a large surrounding background. Antialiasing can make extremely thin lines difficult to perceive even when the nominal colors pass.

Test a representative toolbar at 200% zoom, with keyboard navigation, and with a screen reader. Confirm that each button has a useful name, receives focus once, activates as expected, and shows a visible focus indicator. Check a dark theme and high-contrast settings rather than assuming currentColor solves every state.

Record the naming rules next to the icon component API. Require either visible text or a deliberate accessible label for icon-only variants. Keep asset cleanup separate from semantics: SVG production optimization can reduce markup, but removing accessibility attributes indiscriminately can undo the work.

Key takeaways

• Classify each icon instance before choosing accessibility attributes.
• Hide decorative SVGs while preserving the surrounding label.
• Name icon-only buttons by action, directly on the control.
• Explain informative graphics with meaningful text, not shape descriptions.
• Test contrast, target size, focus, and spoken names in real contexts.