Keyboards and beyond
Many people with disabilities do not use computer mice. Some navigate using a keyboard, and some use alternative input methods, many of which (such as switches, physical pointers, and eye and motion trackers) emulates the behaviour of a keyboard. Therefore, by making sure your website is keyboard-accessible, you are actually serving users of many other technologies.
The basic keys you need to make sure are supported include:
- Tab: to quickly jump through all focusable elements.
- Note: on some browsers, this behaviour doesn’t fully work out of the box. For example, here is an article to help you enable tabbing for all focusable elements on Safari and Firefox.
- Enter: to activate links.
- Space: to activate buttons and many
<input>elements, and to choose an option from a
- Arrows: to switch between options in
<select>dropdowns and groups of radio buttons.
- Escape: to close expanded
All the native HTML elements mentioned above already come with the described functionality, which is implemented by the browser. If you create custom elements, they need to be keyboard-accessible in a way that is consistent with the usual conventions. For example, the user must be able to press Escape to close or dismiss custom elements, such as multilevel navigation menus or modal overlays.
Notes about forms:
- If a button
type=”submit”is inside a
<form>element, pressing Enter while being focused on any element inside the form will trigger form submission, without activating the Submit button itself.
- If a
<form>element has no Submit button, the browser will look for the first button without an explicit type (so, with an empty or missing
typeattribute), but only inside the form. If none can be found, the form cannot be submitted via default browser methods.
Focus order and visibility
The default focus order follows the DOM (Document Object Model). This means that, as a user tabs through the page using the keyboard, interactive elements will receive focus in the order they appear on the HTML code file. It’s possible to modify the focus order with the
You can test focus order by simply tabbing through the page. Focus order should normally follow visual order, although there are exceptions. For example, if a language switcher is visually located at the end of the navigation bar, you can make it come first in the focus order so that keyboard and screen reader users can have the option of changing the language of the page as soon as possible.
All focusable elements must have a visible focus indicator. This is such a key accessibility feature that browsers must provide default focus styles; unfortunately, accessibility issues often arise because the default browser focus is insufficient or has been overridden by developers. You can learn more about good focus styling practices on our Hover, focus, active page, and how to test this on our colour testing page.
- Quick tip: Browser Keyboard Navigation in macOS by Scott Vinkle and Erin Olmon (2019)
- Keyboard accessibility by WebAim
- Keyboard-Only Navigation for Improved Accessibility by Nielsen Norman Group
- Success criterion 2.1.1: Keyboard [Level A] on WCAG 2.1