Making icon labels accessible

How to pair icons with text and aria attributes so they communicate clearly to screen-reader users and visual users alike.

Icons alone are never enough

An icon by itself is ambiguous. The same gear icon means "settings" in one product and "manage" in another. The same downward arrow means "download" in one context and "sort descending" in another. Sighted users disambiguate from context — but screen-reader users don't have that context until you give it to them. The first rule of accessible icon use is that every meaningful icon needs a text equivalent, either visible on screen or available to assistive technology.

Use a visible label whenever you can

The strongest accessible pattern is the boring one: a visible text label next to the icon. "Download" with a downward-arrow icon. "Settings" with a gear icon. "Add new" with a plus icon. Visible labels help everyone — first-time users, low-vision users zooming in, screen-reader users, and the future you who has to redesign the screen and forgot what the icons meant. If the only reason to omit a label is to save horizontal space, ask whether the screen could lose something else instead.

When you must use an icon-only button

Sometimes an icon-only button is the right call — a row of formatting controls in a rich text editor, a constellation of small actions in a data table, a compact mobile bottom bar. In those cases, give every icon-only button an accessible name via the aria-label attribute. The name should match what a sighted user would say if asked what the button does. "Bold," not "B." "Delete row," not "trash." "Add to favorites," not "heart."

Decorative icons need aria-hidden

An icon that sits next to a visible label is decorative from an accessibility standpoint — the label already carries the meaning, and the screen reader doesn't need to announce the icon a second time. Mark these icons aria-hidden="true" so screen readers skip them. Skipping the icon is not rude; it is helpful. A user navigating with a screen reader doesn't want to hear "image, button, settings" — they want to hear "settings button."

Test with a real screen reader

All of the above is theory until you actually navigate your interface with a screen reader. Spend twenty minutes with VoiceOver on macOS, NVDA on Windows, or TalkBack on Android. Tab through every icon-only button on a representative screen and listen to what the screen reader says. The first time you do this, you will find at least one icon that announces something completely confusing. The second time, you will catch most issues at the design stage.

A note on icon fonts

If you are still using an icon font — Font Awesome, Material Icons as a font, or similar — be especially careful. Icon fonts render glyphs as text, which means a screen reader may try to read the underlying private-use Unicode character. The fix is the same as above: aria-hidden the icon span, give the parent button an aria-label, and you will be in good shape. SVG and PNG icons are typically easier to make accessible because they don't carry phantom text content.