Buttons: Keyboard, mouse and touch accessibility
A button must be accessible to people using a keyboard, mouse or touch.
To learn why it’s important to make content keyboard accessible, see the Knowledge Area: Keyboard accessibility.
Keyboard accessibility
Keyboard focusability
A button must be keyboard focusable via the Tab key.
Native HTML buttons
A button created using the <button> or <input> element is keyboard focusable by default using the Tab key.
Custom buttons
If the element used to create the custom button is not natively keyboard focusable, tabindex="0" needs to be added. This puts the button into the keyboard focus order based on its natural position in the HTML markup.
Visible focus indicators
A button must always show a visible focus indicator when it has keyboard focus.
For more information, see Visible focus indicators — Knowledge Area: Keyboard accessibility.
Meeting the Web Accessibility Standard
When a button with keyboard focus always shows a visible focus indicator, this meets WCAG 2 Success Criterion 2.4.7 Focus Visible (Level AA).
Logical keyboard focus order
The order in which a button receives keyboard focus must make sense to the user. That is, the keyboard focus order must be logical in the way that it relates to the surrounding content.
For more information, see: Logical focus order — Knowledge Area: Keyboard accessibility.
Meeting the Web Accessibility Standard
When a button is part of a logical keyboard focus order, this meets WCAG 2 Success Criterion 2.4.3 Focus Order (Level A).
Keyboard operability
A button must be able to be activated using either the keyboard’s Space or Enter keys — and both of these options must be available.
Meeting the Web Accessibility Standard
When a button is operable using the keyboard’s Space key and Enter key, this helps meet WCAG 2 Success Criterion 2.1.1 Keyboard (Level A).
Native HTML buttons
A button created using the <button> or <input> element is keyboard operable by default using either the Space or Enter keys.
Custom buttons
To ensure that keyboard users can activate a custom button using the Space or Enter keys, a keydown event handler is needed so that when the button has focus and either of those 2 keys is pressed, this triggers the button’s action.
If the element used to create a button already responds to some keyboard activation, the keydown event handler only needs to replace any missing keyboard functionality.
For example, a button created from an <a href> with role="button" is already activated by the Enter key, in which case the keydown event handler only needs to listen for and act upon the Space key being pressed.
If the element used to create the button has any default behaviour, as in the case of <a href> (which usually takes the user to another location), prevent that element’s default behaviour with event.preventDefault().
In addition, the Space key’s default behaviour of scrolling the page needs to be prevented by using the keydown event handler associated with the Space key.
For more information, see:
- Responding to keyboard input — Knowledge Area: Keyboard accessibility
- Keyboard interactions — ARIA: button role — MDN Web Docs
- Button Examples — ARIA Authoring Practices Guide — W3C
- Adding and removing event handlers — MDN Web Docs.
Mouse and touch accessibility
Buttons need to work for people who use a mouse or a touchscreen interface.
Native HTML buttons
A button created using the <button> or <input> element already responds to mouse clicks and touch and is therefore accessible.
Custom buttons
If the element used to create the button does not already respond to mouse clicks, a click event handler is required to make the custom button activate on mouse click or touch.
If the element used to create the button does already respond to click events, as in the case of an <a href> element with role="button", mouse and touch activation are already provided. However, the <a href> element’s default behaviour of navigating to another location needs to be prevented with event.preventDefault().
For more information, see: