Icon Button Labels

Icon button labels provide accessible names for buttons that contain only icons without visible text. Proper labeling ensures screen reader users understand what each button does, making icon-based interfaces fully accessible.

What Are Icon Button Labels

Icon buttons contain graphical icons as their only visible content. Examples include close buttons (X icon), menu buttons (hamburger icon), and action buttons (edit pencil, delete trash). Without accessible labels, screen readers may announce these buttons unhelpfully as “button” with no context.

The accessible name tells users what the button does. “Close dialog,” “Open menu,” and “Delete item” communicate button purposes clearly. This name comes from various sources: visible text, aria-label, or referenced labels.

WCAG Success Criterion 4.1.2 (Name, Role, Value) requires that user interface components have accessible names. Icon buttons without labels fail this requirement since icons alone do not provide accessible names.

How to Label Icon Buttons

aria-label provides the most direct approach. The attribute value becomes the accessible name:

Screen readers announce “Close dialog, button” giving users complete information about what the button does and its type.

Visually hidden text provides an alternative that keeps the label in the DOM:

The sr-only class positions text off-screen while keeping it accessible. This approach can benefit SEO and works when aria support is uncertain.

aria-labelledby references another element whose text becomes the label. This works when visible text elsewhere describes the button:

The visible “Delete item” heading labels the button without redundancy.

title attributes provide labels in some contexts but have inconsistent screen reader support. They also require hover to display for sighted users. aria-label or hidden text provide more reliable accessibility.

Key Considerations

• Every icon button must have an accessible name
• Use aria-label for simple, direct labeling
• Use visually hidden text when DOM presence benefits SEO or provides fallback
• Write labels describing the action, not the icon appearance
• Avoid redundant words like “button” in labels (screen readers add the role)
• Consider dynamic labels for buttons whose action changes
• Test with screen readers to verify announcement accuracy

Common Questions

What makes a good icon button label?

Good labels describe the action concisely: “Close,” “Delete,” “Edit,” “Search,” “Menu,” “Settings.” They communicate what happens when activated, not what the button looks like.

Avoid labels like “X icon button” or “Click to close” - screen readers add “button” and the action verb is sufficient. Context sometimes requires more detail: “Delete comment” versus “Delete” when multiple delete actions exist.

Should icon button labels include context?

When multiple similar buttons exist, context prevents confusion. A page with several edit buttons benefits from labels like “Edit profile,” “Edit address,” “Edit payment.” Users can distinguish between buttons without visual context.

When only one button of a type exists, short labels work well. A single settings button can be labeled “Settings” without additional context.

How do tooltips relate to icon button labels?

Tooltips provide visual labels for sighted users who may not recognize icons. However, tooltips require hover, which screen reader users may not trigger. Accessible labels should not depend on tooltips.

Implement both: aria-label for accessibility, tooltip for discoverability. The tooltip text often matches the aria-label. Some implementations tie them together, using the tooltip text as the accessible name.

Summary

Icon button labels provide accessible names through aria-label, visually hidden text, or aria-labelledby references. Labels should describe the button’s action concisely, enabling screen reader users to understand and operate icon-based interfaces effectively.