Multi-action button

Requirements

Users should be able to:

• Navigate to and activate the button.
• Activate the button to open a dropdown menu of secondary options.
• Navigate to each of the secondary options and activate them.

Interactions

Mouse interactions

• Secondary actions are displayed or hidden on click of the button, not on hover.
• Secondary actions remain displayed until one is activated, the button is clicked again, or the user clicks outside of the button and dropdown area.

Keyboard interactions

• Tab. Moves focus from the previous interactive element to the button.
• When activated, it moves focus between the secondary options.
• When focus is moved out of the menu, the dropdown is dismissed.
• Space or Enter. Activates the button, which triggers the display of secondary options.
• If secondary options are links, activate using Enter.
• If secondary options are buttons, activate using Enter or Space.
• Escape. Dismisses the dropdown menu.

Design considerations

• Use a visual cue to show that the button has additional options. 
• Make sure the dropdown near to the button.
• Use clear, concise button names to help users understand the button's purpose.
• Make sure the accessible name of the button matches the visible name.  

Development considerations

• Buttons should have clear accessible names, given by the inner button text.
• If multiple buttons have the same name, use aria-describedby to specify the content each button relates to.
• Give the button an aria-expanded attribute to let screen reader users know the state of the button, and that it has additional actions.
• The secondary options should be contained within an unordered list ul and each option should be contained within a list item li.
• The relationship between the button and the content area should be conveyed using aria-controls.

How it works 

Make sure mouse and keyboard users can use the button. Include a descriptive label, use the minimum contrast ratios, and assign a role to the button.

Accessibility requirements

• Label. Use a descriptive UI label that clearly explains what happens if the user selects the button.
• Color. Give the button a contrast ratio of at least 3:1 against the background.
• Role. Use  or  with role="button" so assistive technologies announce the button and provide button functionality.

ARIA

Use the aria-disabled="true"attribute to indicate a disabled button.

Use a disabled button only if user research and data support using it. Disabled buttons can be difficult to see because the color contrast is poor. Users might not understand that they cannot select the button. Instead of a disabled button, use an active button to trigger errors on the page. Display the error messages visually and programmatically.

Keyboard commands

Testing

We tested the component using the following software.

Computer

Assistive technology

Resources

• Learn about accessibility at Sage
• W3C Button examples
• WAI-ARIA authoring practices guide: Button
• WCAG 2.1 Understanding success criterion 1.1.1: Non-text content
• WCAG 2.1 Understanding success criterion 2.5.3: Label in name
• WCAG 2.1 Understanding success criterion 2.4.7: Focus visible