For a lot of people, when we’re not glued to our mobile device, we’ll be accustomed to using a mouse for getting around online. The keyboard is pretty much relegated to data input; cue a sense of panic if the mouse is ever lost, broken or out of charge.
While clearly optimised for mouse or touch interaction, computers are designed to be fully operational with just a keyboard. Which keys are used will differ depending on whether you use Windows or a Mac, and some tasks will be less efficient when relying on a keyboard (although some are arguably quicker).
Navigating a web page with a keyboard
Web browsers and the Internet support keyboard navigation by default. Developers have to do something to break it (more on that later).
WebAIM has a table of standard key commands for common online interactions, so I won’t cover those in detail here. A key concept to remember (pun intended) is that keyboard users will typically use the Tab key to move forwards from one interactive element to the next, e.g. links, buttons and form inputs. Pressing the Shift and Tab keys allows navigation in the opposite direction. The order in which interactive elements receive keyboard focus when using the Tab key is known as the tab order.
Who uses keyboard navigation?
I have been flippant about how people may struggle without a mouse, but for some people using a mouse is simply a non-starter, as shown in this keyboard compatibility video from the Web Accessibility Initiative. Keyboard navigation is essential for:
- People with conditions affecting mobility and manual dexterity, such as arthritis, repetitive strain injury, carpal tunnel syndrome, Parkinson’s disease, or paralysis.
- People who use Assistive Technology to facilitate or emulate keyboard use, e.g. mouth sticks, head pointers, eye trackers, sip-and-puff software or speech input software.
- Blind people using screen readers, which are designed to function via keyboard commands (and offer more options than just tab navigation).
- People with temporary injuries affecting the arm or hand.
Additionally, some “power users” simply prefer using a keyboard instead of a mouse.
What obstructs keyboard navigation?
Common accessibility problems for keyboard users include:
- Interactive elements that only work when clicked on with a mouse or other pointer device.
- Content that is only revealed when a triggering element is hovered with a mouse, such as “tooltips” and hover navigation.
- Keyboard traps, where people navigating with their keyboard navigate to a certain part of the page but cannot leave it.
- Pop-up windows that cannot be closed using the keyboard and obscure the page content.
- Lack of a visible focus indicator, leaving keyboard users uncertain as to where they are on the page.
- Items that are hidden on screen but still receive keyboard focus.
- A confusing tab order that doesn’t match the visual order of items on the page (usually left to right, top to bottom).
- No skip link to help keyboard users quickly jump over blocks of content they do not want to have to tab through, such as the navigation at the top of this web page.
Some of these issues make keyboard navigation more challenging (both physically and mentally) than it needs to be; some will make a website completely unusable.
How to support keyboard navigation
Keyboard accessibility is one of the most straightforward accessibility techniques to get right. As I mentioned earlier, developers usually have to go out of their way to break it, so it’s a case of making good decisions to avoid introducing problems for people.
Use the right HTML elements for providing interactivity
- Use <a> for navigating to new web pages or areas within the current page.
- Use <button> for actions such as submitting forms, revealing hidden content and closing pop-ups.
- Use native <input> elements for form fields.
These elements all support keyboard navigation without the need for any extra effort ‒ note that the <a> element must have a non-empty href attribute. Using a <div> or <span> to replace any of these elements may seem like an easier option in terms of styling, but will require additional effort to make them fully keyboard accessible.
Poorly-implemented cookie banners and pop-up windows are a common challenge for keyboard users, where the control to dismiss the attention-seeking panel is either a link without the href attribute, a <div> or a <span> customised with JavaScript that does not support keyboard access. Without a way for keyboard users to close it, that panel risks obscuring some or all of the page content. This is even worse for people who also need to zoom in their display. If focus is automatically moved to the panel when it first appears and there is no way for a keyboard user to close it, it becomes a keyboard trap.
Avoid interactions that rely on hover
As well as being inaccessible to screen reader users and people navigating via keyboard, hover interactions can be poor for usability more generally. Having things pop up on screen when you are just trying to move your mouse to a different part of the page can be very irritating. Plus, while there is no traditional hover state on a mobile device, people can connect a keyboard to their mobile phone.
If you decide to support keyboard focus alongside mouse hover, you will need to make sure that the content revealed is dismissible, hoverable and persistent in line with the Web Content Accessibility Guidelines.
Avoid disabling the visible focus indicator
When an interactive element receives keyboard focus – i.e. somebody has tabbed to it – the browser provides a visible indicator that lets sighted users know the element is ready for them to interact with (and simultaneously confirming their location on the web page). This usually involves placing an outline around the focused element.
You can customise the appearance of the default focus indicator if you find it unappealing, but don’t disable it by setting the outline style to none or zero.
Provide skip links and avoid redundant links
Unlike sighted mouse users, who can visually scan a web page and click directly on any link, keyboard users have to tab their way through all the interactive elements that come before the one they actually want to interact with. It is tiresome having to tab through the same set of navigation links on every page in a site, more so if there are a lot of them. To mitigate this, provide a skip link at the start of the web page to take keyboard users directly to the main content region of the page.
Another consideration to make keyboard navigation more efficient is to avoid redundant links, i.e. adjacent links that go to the same destination. A classic example is linking an image to another page and separately linking adjacent text to that same page. A person navigating with their keyboard has to tab twice rather than once when navigating through that area of the page. If there is a need for both the image and text to be linked, combine them into a single link.
Use the correct technique when hiding content
Some websites have separate navigation menus for mobile and desktop screens, with only one version showing at a time. Navigation that is hidden visually must also be hidden from keyboard navigation to avoid a frustrating and confusing user experience. Placing content offscreen with large negative margins and reduced opacity is not sufficient, as links hidden in this way can still receive keyboard focus. Scott O’Hara has written about the different techniques for hiding content.
Maintain a logical navigation order
Tab order, which I described earlier, is really important for keyboard users. To avoid causing confusion, it should broadly match the natural reading order of page content, which for most languages flows from left to right and top to bottom.
The default keyboard navigation order (and screen reading order) of page content is determined by the structure of the underlying HTML markup. This source order should guide people logically through the content. It is not a good idea to override navigation order with tabindex and shouldn’t be necessary when using semantic HTML.
When adapting page layout with CSS, be aware that Flexbox and Grid make it easy for the visual navigation order to diverge from the source order in ways that can be very confusing for some people.
Test your website for keyboard accessibility
Checking how well your website works with a keyboard is such a revealing and worthwhile exercise. The DWP Accessibility Guide has an excellent resource on how to test keyboard accessibility, and discusses the impact of keyboard accessibility issues on users. Accessibility Insights has an assisted test for Tab stops that includes a handy visual helper.