Buttons
Button elements draw attention to events. Use clear button labels to let the user know what action they will trigger.
Default buttons
Default buttons help users execute primary actions on a page.

When to use
- Use the button component to help users carry out a meaningful action. Actions can include starting an application, saving information, or expanding and collapsing accordions.
When not to use
- Don’t use buttons in place of links. Screen readers treat links and buttons differently. If you need to style a link to look like a button, use CSS.
Create clear button labels
When using icons as buttons, use aria-label
or aria-labelledby
. This will give the button an accessible name. For example: an arrow icon for a next page button.
When using an icon and text within a button, make the icon hidden to screen readers using aria-hidden=”true”
. The icon image is redundant if a button is already labeled.
Don’t rely only on the use of color to convey the seriousness of the action. Not all users can distinguish color or know what it signifies. Warning buttons are often red. Use color, context, and button text to state what will happen if the user clicks the button.
Identify expand-collapse state
Use aria-expanded
attribute on the button. This lets screen reader users know if an accordion state is expanded (“true”) or collapsed (“false”).
Avoid disabled buttons
Avoid using disabled buttons, especially in forms. Disabled buttons provide no feedback. No feedback makes it hard for users to know why they can't use the button. Instead, use validation and errors to show the user what they still need to do. If you must have a disabled button, use the aria-disabled attribute. This will notify screen readers of the button’s existence. You must also create extra styling and event listeners. These will ensure the disabled button is accessible.
Focus on the most important actions. Too many actions on a page can confuse users. Use consistent locations for button positioning on the interface.
Use the right button style
Use button style to guide users.
- Primary - for the main action the user could take.
- Secondary - for supporting actions.
- Tertiary - for low priority optional actions.
Use large buttons 44px by 44px in all public facing applications. This is a comfortable and accessible touch point size for both desktop and mobile devices. This ensures buttons are easy to tap for all users, including those with motor impairments.
Small buttons: May be appropriate for use in internal tools. This is because users are more familiar with the inferences. Always check that the buttons remain visually clear and keyboard accessible. Interactive targets can include white space around the target. This meets WCAG 2.1 AA standard.
Write effective button labels
Make button labels concise and clear enough to state the action the user will take.
- Use strong action verbs or phrases. For example, use verbs like submit, register, sign up, donate, etc.
- Avoid long, redundant button labels. Drop unnecessary articles, such as: a, or, and the for more concise labels.
- Use a verb and a noun. For example: start survey.
- Write buttons in sentence case. Capitalize only the first word unless using a proper noun.
Secondary buttons
Secondary buttons help users execute supporting actions related to a primary button. Examples of secondary buttons include Back and Cancel. They should not be as noticeable as primary buttons.

Warning or danger button
Warning buttons interrupt users before taking a destructive action. For example, a button would warn a user before permanently deleting an account. They only work if we use them for rare, specific events. Most services should not need one. When needed, include a step asking users for final confirmation.

Disabled button
Disabled buttons display as greyed out. Users can’t interact with them. A user should understand they can’t do the action associated with them. Disabled buttons have inherent issues with accessibility so use them only very sparingly. It’s better to keep a button enabled and show an error message explaining why the user cannot proceed.

Disabled buttons block users without informing them what is wrong. Avoid using disabled
, especially for form submissions.
Disabled buttons generally have poor color contrast. This can confuse users who are visually impaired.
Use aria-disabled=”true”
to make the button disabled and visible to screen readers. This helps the button receive focus on tab and notifies the screen reader user of its existence.
The aria-disabled
attribute requires both CSS and JavaScript/TypeScript. This toggles between an element as enabled or disabled. Mozilla article on the aria-disabled attribute.