What the component handles
- Screen reader announcements for loading and disabled state.
- Meets minimum target size requirements.
- Icons are decorative and hidden from screen readers.
What you need to provide
- Preferably, a unique and descriptive button text that explains the action or use aria-label attribute to provide more context for screen reader users (read more below).
- counterAccessibleText property to describe counter for screen readers (e.g., "3 notifications").
- Additional ARIA attributes when you compose the button into larger patterns, e.g.
- aria-expanded for dropdowns,
- aria-controls for modals,
- aria-pressed for toggle buttons,
- aria-haspopup for menus.
- When setting a button's loading prop to “true“, you must also provide an aria-label with a descriptive value. This ensures that screen readers can properly communicate the button's loading state to users.
- When a button enters a loading state, its visual appearance changes and it shows a spinner), but this visual change alone doesn't convey information to users relying on assistive technologies. The aria-label provides the necessary context about what the button does so screen reader users can understand what action is being performed.
Color contrast
All variants meet the WCAG 2.1 AA color contrast ratio requirements and can be used on the following:
- background.static.xxx tokens except for background.static.inverse and background.static.on-color
- in all Card variants,
- in Banner components.
Other accessibility considerations
Do not mix the usage of buttons and links
Remember, buttons are for triggering actions, not navigating. Misuse confuses keyboard and screen reader users, who may hear them announced by the wrong role.
Make sure button labels are unique and descriptive
Text labels like “View all” and “+Add” don’t provide enough context for the screen readers. If the UI doesn’t allow for a more descriptive and unique label, use an aria-label attribute to provide an alternative, e.g., “View all messages” or “Add breakfast to your order”.
When possible, use medium or large variant buttons
Although Small Buttons meet the AA target size requirements, Medium or Large Buttons should be used when possible to cater the needs of users with fine motor control difficulties or limited dexterity.
On mobile devices, it is recommended to use the Extra Large Buttons to ensure smooth touch interactions.
Disabled buttons
Avoid using disabled buttons, especially in forms. Disabled buttons don't explain why they aren't usable, and they aren't visible to people using keyboard navigation. Instead, keep the button enabled, using validation and errors to explain what needs to be done to continue.