Accessibility

Accessibility

Icon Buttons are interactive components that rely solely on visual cues (icons, outlines, and focus rings) to convey meaning. Because they don’t include text, ensuring accessibility through proper semantics, focus management, and colour contrast is essential.

For Design

Minimum touch area

To ensure accessibility and ease of interaction across devices, all interactive elements — including Icon Buttons — must respect a minimum touch target size.

Absolute minimum: 24 × 24 px — This is the lowest technical requirement referenced in accessibility standards (WCAG 2.5.5, EN 301549). It ensures the button can still be reached, but doesn’t guarantee an optimal experience for all users.

Recommended best practice: 44 × 44 px — Provides a comfortable interaction area for users with motor impairments, touch devices, or outdoor use. Should be considered the default requirement for Icon Buttons in our system.

The minimum target size applies regardless of the visual size of the icon or container. If the visual element is smaller (e.g. small icons or outlined variants), add invisible padding to meet the required target area. Maintain consistency across all sizes (LG, MD, SM) and across both styles (Filled / Outlined).

Guidance on how to use a component.

• Add invisible padding to meet the minimum touch size without altering the visual design.
• Ensure the button remains tappable and clearly identifiable in responsive layouts and mobile contexts.
• Keep spacing between Icon Buttons to at least one touch target (avoid overlapping targets).

Guidance on what to avoid when using a component.

• Don’t rely on the visible icon size to define the touch area.
• Don’t define interactive areas smaller than the minimum, even for small icons.
• Don’t cluster multiple Icon Buttons too closely, as this can make interaction difficult for users.

For Dev

To ensure Icon Buttons meet accessibility standards across platforms, follow this implementation checklist. These recommendations align with WCAG 2.2 AA and EN 301549, supporting keyboard navigation, screen readers, and assistive technologies.

1. Screen reader support
   • Use semantic <button> elements for all Icon Buttons.
   • Each button must include a descriptive aria-label that clearly communicates its purpose.
   • When used as toggles, add aria-pressed="true" or "false" to indicate the current state.
   • Avoid using decorative icons alone — hide them from assistive tech with aria-hidden="true".
   • Never use <div> or <span> elements styled as buttons, as they break keyboard semantics.
2. Keyboard navigation
   • Buttons must be focusable via Tab and activatable via Enter or Space.
   • Maintain a visible focus state at all times, consistent with the visual design.
   • Avoid intercepting default keyboard behaviour unless required (e.g. arrow keys for carousels).
   • Ensure sufficient contrast between link focus indicators and adjacent elements (minimum 3:1).
3. Motion sensitivity and feedback
   • Avoid any animations that trigger automatically or on hover.
   • Respect user preferences (prefers-reduced-motion).
   • Motion should always support, not replace, visual state changes.
4. ARIA and markup
   • Always expose the button role and name to assistive technology (role="button", aria-label="...").
   • Use aria-pressed for toggle buttons and aria-busy for asynchronous actions.
   • Use aria-live="polite" for status updates triggered by Icon Buttons (e.g. loading states).
5. Testing and validation
   • Validate accessibility using tools like Axe, Lighthouse, or Accessibility Insights.
   • Verify focus visibility under both light and dark modes.
   • Test manually using keyboard navigation to ensure expected behaviour and focus order.