Icons can make an interface easier to scan, but a symbol that seems obvious to one person may be confusing or invisible to someone else. A magnifying glass may suggest search, while an unfamiliar symbol might leave visitors guessing. An icon without a useful name can leave a screen reader user guessing too.

Accessible icons are not just a matter of adding alt text everywhere. The right approach depends on what the icon does, whether nearby text already communicates its meaning, and how people interact with it. This guide covers the decisions designers, developers, and content teams can make to use icons and symbols more inclusively.

Start With the Icon’s Purpose

Before choosing a label or writing code, ask what the icon contributes:

  • Decorative: A small arrow beside a clearly labeled link adds visual interest but no new information.
  • Informative: A warning symbol conveys important information that is not otherwise available in text.
  • Interactive: A close icon acts as a button, or a home icon serves as a link.

The distinction matters. An informative image needs an equivalent text alternative. A decorative image should not add redundant announcements. An interactive control needs a name that describes its action or destination. If an icon’s purpose changes with context, its accessible treatment may need to change too.

For the underlying rules, see the W3C’s guidance on non-text content and name, role, and value.

Prefer Clear Text Alongside Icons

When space allows, pair an icon with a visible label such as Search, Download report, or Delete draft. A recognizable icon can make the control quicker to find, while the text removes ambiguity for people who do not recognize the symbol. Visible labels also help people using speech input refer to controls by the words they see.

For example, a trash can could mean delete, clear, or discard. The label Delete draft says exactly what will happen. Use the same icon for the same action across your site, and avoid using one icon for unrelated actions.

A visible label can also provide the button’s accessible name. For example, place a trash can image inside a button labeled Delete draft. Give the image alt="" because the text already identifies the action. The empty alt tells assistive technology to skip the image. Do not use an empty alternative for the only content of a meaningful control unless the control is named in another appropriate way. Also, do not hide a button or link from assistive technology just because its icon is decorative.

Give Icon-Only Controls an Accessible Name

Sometimes an icon-only control is appropriate, such as a close button in a dialog. Use a native <button> for an action or an <a> for navigation, and give the control a concise name that describes its purpose. Name the action, not the shape of the icon.

For example, add aria-label="Close dialog" to a native button containing a close icon. If the icon is an inline SVG, add aria-hidden="true" to the SVG because it repeats the button’s purpose. The application must also make the button actually close the dialog and handle focus appropriately.

A few practical rules:

  • Use a name such as Search, not Magnifying glass.
  • Give repeated controls enough context. Remove blue shirt from cart is more useful than several buttons all named Remove.
  • If a control has visible text, keep that text in its accessible name. Prefer deriving the name from the visible text instead of overriding it unnecessarily.
  • Do not rely on a tooltip or the title attribute as the only way to explain an icon. Important information should be available without hovering.

Native controls provide useful semantics and keyboard behavior. A clickable <div> with an icon does not automatically behave like a button. Read more in our keyboard accessibility guide.

Treat Decorative and Informative Icons Differently

If an image icon is purely decorative, use alt="". For a decorative inline SVG, aria-hidden="true" can remove the SVG from the accessibility tree. Apply it to the icon, not to its interactive parent or a container with meaningful content.

If an icon communicates information not otherwise present, provide an equivalent text alternative or, preferably, visible text. For example, a warning triangle next to Payment failed does not need a second announcement saying Warning triangle. The text already communicates the important message.

If a star graphic is the only way a rating is shown, provide the actual rating, such as 4 out of 5 stars, rather than a description like Four gold stars. If that same rating is already written beside the graphic, hide the redundant graphic from assistive technology instead.

Review icons in context. The same checkmark can be decorative beside Completed but meaningful if it is the only indicator that a task is complete.

Do Not Rely on Color or Shape Alone

Color can reinforce a message, but it should not be the only visual way to convey it. A red circle and a green circle may be hard to distinguish for some visitors. Add text such as Error and Success, or use clearly different symbols as well as color. Text is especially useful when symbols might be unfamiliar.

Similarly, avoid expecting people to infer important meaning from a shape without context. A triangle can mean warning, play, or expand depending on where it appears. Use a label or supporting instruction where the meaning is not clear.

For more examples, see our guide to color blindness and web accessibility and the W3C’s use of color guidance.

Check Contrast, Size, and Focus

An icon may have a perfect accessible name and still be difficult to see or use. Check it in every state, including hover, focus, selected, and error states.

Contrast: WCAG 2.2 Level AA generally requires at least 3:1 contrast against adjacent colors for parts of graphics needed to understand their content, and for visual information needed to identify a control or its state. Exceptions apply, including inactive controls. A purely decorative icon does not have to meet this non-text contrast requirement simply because it is an icon. Check the actual colors next to each meaningful part, not just the icon against one assumed background. See the W3C’s non-text contrast explanation for details.

Target size: Give interactive icons enough room to activate without accidentally hitting a neighboring control. WCAG 2.2 Level AA generally requires a target of at least 24 by 24 CSS pixels or sufficient spacing, with defined exceptions. A larger target can be more comfortable. The clickable area can be larger than the visible icon. See target size minimum for the full rule and exceptions.

Focus: When someone tabs to an icon button or link, a visible focus indicator should make it clear which control is active. Test against the surrounding colors and avoid designs that remove the browser’s focus indicator without providing a usable replacement.

Make State Changes Understandable

Icons often communicate changing states: a menu opens, a favorite is selected, or an item is added to a cart. Make the state clear visually and programmatically where appropriate.

For a menu button, keep a clear name such as Account menu and update aria-expanded to reflect whether the menu is open. For a toggle button, use an appropriate state such as aria-pressed, and make the selected state visible without relying on color alone. The application must update these attributes as the state changes. ARIA describes behavior to assistive technology; it does not create the behavior itself.

For a status change that is important but does not move focus, consider whether an appropriately implemented status message should announce it. A brief visible message such as Item added to cart can also reassure sighted visitors. Test the real interaction rather than assuming that changing an icon alone is enough.

A Quick Icon Accessibility Review

Choose a representative page and work through this checklist:

  1. Inventory the icons. Include navigation, forms, status messages, dialogs, and mobile layouts.
  2. Identify each purpose. Is the icon decorative, informative, or interactive? Is its meaning already available in visible text?
  3. Review labels. Make visible labels clear, and confirm each icon-only control has an accessible name that matches its action or destination.
  4. Use a keyboard. Tab to every control, look for focus, and check that the expected keys operate it.
  5. Test with a screen reader. Listen for the control’s name, role, and state. Check that decorative icons are skipped and repeated labels have enough context.
  6. Inspect the visuals. Check meaningful contrast, target size and spacing, and whether states are distinguishable without color alone.
  7. Test changes and responsive layouts. Open menus, trigger errors, change toggle states, zoom in, and repeat the checks on a narrow screen.
  8. Ask real users for feedback. When possible, include people with disabilities in testing to catch confusing symbols and workflows that a checklist may miss.

Automated checks can help find some issues, but they cannot decide whether an icon’s meaning makes sense in context. Combine them with manual testing. Our website accessibility audit guide explains how to turn findings into a remediation plan.

Start Improving Your Website

Clear labels, appropriate text alternatives, visible states, and real-world testing can make small icons much more useful to more people.

Sign up for Accessible Metrics and start a free website accessibility scan. Use the results as a starting point, then review your icons and interactions manually to understand how they work for real visitors.