Icon Accessibility
Icon Accessibility
Icon accessibility ensures symbolic graphics communicate effectively to all users through proper labeling for meaningful icons and hiding for decorative ones. Accessible icon implementation varies based on whether icons stand alone or accompany text.
What Is Icon Accessibility
Icons are symbolic graphics representing concepts, actions, or objects. They appear throughout interfaces in navigation, buttons, status indicators, and informational contexts. Icon accessibility ensures these visual symbols have appropriate text alternatives for screen reader users.
The accessibility approach depends on icon context:
- Decorative icons accompanying text labels should be hidden
- Standalone icons representing actions need accessible labels
- Informative icons conveying status need text alternatives
WCAG requires text alternatives for non-text content (1.1.1) and properly labeled controls (4.1.2). Icons must either contribute their meaning accessibly or be hidden to avoid confusing announcements.
How Icon Accessibility Works
Decorative icons that accompany visible text should be hidden from screen readers. The text label provides the accessible name; the icon adds visual interest only. Use aria-hidden=“true” on the icon:
The screen reader announces “Settings” from the text span; the icon adds visual context for sighted users without creating redundant announcements.
Standalone icons that serve as the only label need accessible names. For icon buttons, aria-label on the button provides the name:
The button has no visible text, so aria-label provides what screen readers announce. Alternative approaches include visually hidden text inside the button.
Icon fonts require careful handling. Font icons use Unicode characters or private-use area codes that screen readers may try to announce. Always hide icon fonts with aria-hidden and provide separate accessible labeling.
SVG icons offer more direct accessibility. Inline SVGs can include role=“img” and aria-label directly. This self-contained approach often provides cleaner implementation than icon fonts.
Key Considerations
- Hide icons that accompany visible text with aria-hidden=“true”
- Provide accessible labels for standalone icons using aria-label or hidden text
- Never rely on icon appearance alone to convey meaning
- Use consistent icon-action associations throughout the design system
- Document which icons are recognized and which need text accompaniment
- Test icon buttons with screen readers to verify announcements
- Consider icon recognition: unfamiliar icons need visible labels
Common Questions
When should icons be accompanied by visible text?
Icons should include visible text labels when:
- The icon is not universally recognized
- The action is important enough that misinterpretation causes problems
- Users are unfamiliar with the interface
- Space allows for text without excessive crowding
Common icons like close (X), search (magnifying glass), and home (house) are widely recognized. Less common actions benefit from visible labels. Mobile constraints may require icon-only interfaces with accessible labeling.
How should icon tooltips work with accessibility?
Tooltips can supplement but not replace accessible names. An icon button should have aria-label regardless of whether a tooltip appears on hover. Screen reader users may not trigger hover states.
Tooltips themselves should be accessible: focusable triggers, keyboard-accessible display, sufficient display time. They provide additional context for all users but accessibility cannot depend on tooltip visibility.
What about icons that indicate state?
Icons indicating state (checked, error, loading) must communicate that state accessibly. Color changes alone are insufficient. Options include:
- aria-label that includes the state
- Visually hidden text describing the state
- aria-live regions announcing state changes
- ARIA states (aria-checked, aria-invalid) on associated controls
The state information the icon conveys must be available through non-visual means.
Summary
Icon accessibility hides decorative icons while providing accessible labels for standalone icons through aria-label or visually hidden text. The approach depends on whether icons accompany text or stand alone, with consistent implementation across the design system ensuring predictable experiences.
Buoy scans your codebase for design system inconsistencies before they ship
Detect Design Drift Free