Buttons: Name, role and states

A button needs certain properties programmatically exposed so that users who rely on assistive technologies know what component they’re dealing with.

Programmatically exposing content means assigning certain markup to it so that software or machines can reliably interpret what it is.

To learn about why it’s important to programmatically expose certain information about user interface elements, see the Knowledge Areas:

Accessible name

A button must have a programmatically determinable accessible name. This name is how assistive technologies, like speech recognition and screen reader software, identify and refer to the button. Ideally, the name clearly indicates what the button does or what it controls — for example, ‘Menu’ or ‘Sign in’.

Meeting the Web Accessibility Standard

When a button has an accessible name, this helps meet WCAG 2:

How buttons get accessible names

Interactive components like buttons can get their accessible names in different ways.

For some examples of how to give buttons accessible names, see Buttons and the Baader–Meinhof phenomenon — Manuel Matuzovic.

To learn how components get accessible names and how assistive technologies present them to users, see the following Knowledge Areas:

Accessible name must include any visible text label

If a button has a visible text label (the microcopy on the button), its accessible name must include all of the text in the label, no matter how the accessible name is derived.

To learn more about the difference between an interactive component’s label and name, see “Label” and “Name” as Defined in WCAG — WebAIM.

Typically, a button’s accessible name will be derived from its visible text label, in which case the accessible name will exactly match the label.

However, if a button’s accessible name is derived from some other content, make sure that the accessible name includes all of the text that’s in the button’s visible text label, if it has one.

Example of a visible text label in a hidden accessible name

A button for submitting a search has a visible text label of ‘Go’, but a visually hidden accessible name of ‘Submit search’ via the aria-label attribute.

In this case, a speech recognition user might be saying the button’s visible text label “Go” in order to submit their search, but nothing happens because the button’s accessible name is actually ‘Submit search’.

To solve this, ensure that the button’s accessible name includes any text that’s visually presented in the button — for example, aria-label="Go search!".

Meeting the Web Accessibility Standard

When a button’s accessible name includes all of the text that’s in the button’s visible text label, this meets WCAG 2 Success Criterion 2.5.3 Label in Name (Level A).

Role

A button needs to have a role of button, so that users who rely on assistive technologies can know what type of user interface component it is. This lets them know what to expect and how to interact with it.

Meeting the Web Accessibility Standard

When a button has a role of button, this helps meet WCAG 2:

Native HTML buttons

If you create a button using native HTML methods, such as <button> or <input type="submit">, the browser already assigns it a role of button.

Custom buttons

If you create a custom button out of other elements, the button role needs to be added explicitly.

This requires using ARIA to give the element a role attribute with a value of button.

Example of a role attribute with a value of button
<div role="button">

More information on the button role

States

All interactive elements, like buttons, have different states.

A button can have the following basic states:

Meeting the Web Accessibility Standard

When a button’s state is visually indicated and also programmatically exposed, this helps meet WCAG 2 Success Criterion 1.3.1 Info and Relationships (Level A).

When a button’s different states are programmatically exposed, this helps meet WCAG 2  Success Criterion 4.1.2 Name, Role, Value (Level A).

Programmatic presentation of states

States need to be programmatically exposed so that users of assistive technologies know, for example, whether:

States exposed by the browser

A button’s basic states are automatically registered and exposed programmatically by the browser, so no further work is needed.

Custom states

If a button is used in some custom widget, it might have other states that the developer will need to ensure are being programmatically exposed for assistive technologies. What those states are will depend on the function of the button.

Examples of custom states
  • Toggle button: For a toggle button, use the aria-pressed attribute to indicate whether it’s pressed (on) or unpressed (off).
  • Expand and collapse button: For a button that expands and collapses some content, such as an accordion widget, use the aria-expanded attribute to express the expanded or collapsed state of the content that the button controls.

Visual presentation of states

To help sighted users, a button’s states can be styled visually using the related CSS pseudo-classes:

If a button has been disabled, browsers will apply a default visual style, typically a grey background with low contrast text, but the page author can change this style. Learn more about the accessibility considerations related to disabled buttons.

For more information on visually styling buttons and their states, see Designing Button States — Cloud Four.

Note: A button’s focus states needs an obvious visual style so that sighted keyboard users know that the button has focus and is ready to be interacted with.

For more, see Visible focus indicators — Knowledge Area: Keyboard accessibility.

More information on button states