SVGPulseMaking icon buttons understandable and accessible
An icon button has to explain an action without relying on a full visible sentence. That can save space, but it also makes ambiguity easy. A magnifying glass may mean search, zoom, or inspect. Begin by deciding whether the interface really benefits from removing the visible label.
Name the action
Use a real button for an action and a link for navigation. Give an icon-only button an accessible name that describes what it does, such as Close dialog, not Cross icon. For a visible text button, let the text provide the name and treat the icon as decoration. Tooltips can help sighted users discover unfamiliar controls, but should not be the only way to obtain the control's name or understand its purpose.
Separate decoration from information
A small arrow beside Continue often repeats what the label already explains. A warning symbol beside an error message may reinforce meaning but should not replace the error text. When an image is decorative, avoid making assistive technology announce it separately. For an image element, that usually means an empty alt attribute. For decorative inline SVG, aria-hidden can keep it out of the accessibility tree. Do not hide the containing interactive button.
Give the control room
The artwork can be small while the interactive area is comfortably padded. Check spacing between adjacent controls and try using them with one hand on a phone. Do not crop the focus outline with an overflow rule on a decorative wrapper. Make sure the focus indicator remains visible against both light and dark backgrounds, including when a sticky header overlaps the area around the button.
Explain changing states
A favorite button should communicate whether the item is currently saved. For a toggle, an appropriate pressed state can complement the visible change. Do not depend only on a green or red icon to explain a result. Add text or another clear cue for errors and confirmations. When a control starts a long operation, indicate that work is in progress and prevent accidental repeated submissions without removing all context.
Run a small manual check
Navigate using only the keyboard and confirm that every button receives focus in a useful order. Activate it with the standard button keys. Inspect the accessible name using browser accessibility tools, then test the actual experience with a screen reader when possible. Finally, ask someone unfamiliar with the interface what each visible symbol means. If their interpretation differs from the action, improve the label or choose a clearer icon.
Implementation example
<button type="button" aria-label="Close dialog">
<svg aria-hidden="true" width="20" height="20" viewBox="0 0 24 24">
<path d="m6 6 12 12M18 6 6 18" fill="none" stroke="currentColor" stroke-width="2"/>
</svg>
</button>Walk through a favorites control
A heart beside an item can mean save, like, favorite, or follow. Choose the intended action first and give the control a name that fits the product. One approach uses a stable label such as Favorite and exposes whether the toggle is pressed. Another uses action wording such as Save item and Remove saved item with an appropriate state model. Avoid mixing these approaches inconsistently across a page. The visible filled-heart treatment can reinforce the state, but should not be the only information available. Test the change with keyboard input and a screen reader, then check that the control still makes sense when the network is slow. If saving fails, communicate the failure and restore the correct state. A visually successful animation must not leave the person believing that an action completed when it did not.
Check a dialog's close button in context
The close symbol is only one part of a usable dialog. Confirm that focus enters the dialog in a sensible location, remains in the intended modal interaction, and returns to an appropriate control when the dialog closes. The close button needs an understandable name and a visible keyboard focus indicator. Its hit area should include comfortable space around the cross, even if the drawing itself is small. Test the dialog at a narrow width and at increased browser zoom: a close button positioned outside the panel can become clipped or unreachable. If the content scrolls, ensure the person can still find a way to dismiss it. Consider whether Escape should close the dialog and whether closing could discard unfinished work. These decisions belong to the dialog's behavior, not to the SVG path that draws the cross.
Use a short review script with real tasks
Give a tester a concrete goal, such as saving an item, opening its details, and closing the detail panel. Ask them to complete it using only the keyboard first. Observe where focus appears, whether the control's purpose is clear, and whether success or failure is understandable. Repeat with a screen reader where possible, paying attention to repeated names such as Button or Icon that do not explain an action. Then review the same controls on a phone, including nearby targets that might be tapped accidentally. Automated accessibility checks can catch some missing labels and structural problems, but they cannot decide whether a particular symbol communicates the right concept. Record specific failures and improve the component instead of treating a clean automated report as proof that the interaction is accessible. Reuse the review script when the icon or surrounding layout changes.
Continue reading: Using currentColor for icons in light and dark themes
Try it with an icon
Browse a collection, customize an icon in the studio, and review the result in your actual project.
Browse icon collections →