Plenty of people visit websites without ever touching a mouse. They move through each page with the Tab key, the arrow keys and Enter. Some do it by choice and many do it because a mouse is not an option for them.
If your site falls over for those visitors, they leave. The good news is that keyboard friendly design is mostly about good habits in the build. Here is what to look for and how to test it yourself.
Who relies on a keyboard
The Web Content Accessibility Guidelines (WCAG) are published by the World Wide Web Consortium. The W3C explanation of the WCAG keyboard success criterion lists who benefits. It includes blind people, who cannot use a mouse that relies on eye and hand coordination. It also includes people with low vision who struggle to track a pointer and people with hand tremors.
Keyboard access also helps people who use alternate keyboards or keyboard emulators. The W3C names speech input, sip and puff systems, on screen keyboards and scanning software. These tools send keyboard style commands to the page. If a feature only works with a mouse, these visitors cannot use it.
That link to speech input is worth noticing. Our post on voice search optimisation covers how people speak to search engines. Some people also use their voice to move around the sites they land on. A keyboard friendly build supports them too.
Everything should work from the keyboard
WCAG success criterion 2.1.1 Keyboard is a Level A requirement. It says all functionality of the content should be operable through a keyboard interface. It also says this should not require specific timings for individual keystrokes. In plain terms, every menu, button, slider and form should work without a mouse.
There is a narrow exception. It covers functions that depend on the path of the user’s movement, such as freehand drawing. The W3C is clear that dragging an object to a spot or resizing a window does not count. Those actions only care about where you start and finish.
Common trouble spots on business sites include dropdown menus that only open on hover. Image galleries, carousels and custom booking widgets can also be a problem. Chat popups and cookie banners are frequent offenders. Test each of these with the keyboard before launch.
Never trap the visitor
WCAG 2.1.2 No Keyboard Trap is also at Level A. If focus can move into a part of the page with the keyboard, it must be able to move out again with the keyboard. If leaving needs anything other than the usual arrow or Tab keys, the visitor must be told how. The W3C notes that traps often happen with embedded content and custom widgets.
Restricting focus is allowed in some cases, such as a modal dialog. The visitor just needs a clear way out. The Escape key is a common standard exit. A visible close button that works with Enter is a sensible extra.
Show where focus is
WCAG 2.4.7 Focus Visible is a Level AA requirement. It says any keyboard operable interface should have a mode where the keyboard focus indicator is visible. That indicator is usually an outline or highlight around the link or button that is active. The W3C adds that it should not disappear after a time limit.
A common problem is a theme that removes the browser’s default focus outline for looks. The page might seem cleaner to a mouse user, but keyboard users lose their place. If your designer wants a different style, ask for a custom focus style rather than none. It should be clear against your colours.
Theme choice plays a big part here. When you weigh up the questions to ask before choosing a WordPress theme, add keyboard access to the list. Tab through the theme demo before you buy. If you cannot see where you are, keep looking.
Keep focus out from behind sticky content
WCAG 2.2 added success criterion 2.4.11 Focus Not Obscured (Minimum) at Level AA. It says that when a component receives keyboard focus, it should not be entirely hidden by content the author created. The W3C explanation of focus not obscured lists common causes. They include sticky headers and footers, non modal dialogs and cookie banners.
The W3C describes several fixes. CSS scroll padding can stop a sticky header from covering the focused item. A cookie banner can be made modal or set to close when it loses focus. Content that pushes the page down, such as an accordion, avoids the overlap altogether.
A logical order and a way to skip ahead
WCAG 2.4.3 Focus Order is a Level A requirement. Where the order affects meaning or operation, focusable items should receive focus in an order that keeps their meaning and use intact. The W3C gives the example of a form that jumps between unrelated sections, which fails. A good test is whether the Tab order follows the reading order of the page.
WCAG 2.4.1 Bypass Blocks is also at Level A. It asks for a way to skip blocks of content repeated across pages, such as the main menu. A skip link at the top of each page that jumps to the main content is one listed technique. Headings at the start of each section and ARIA landmarks are others.
Skip links can be hidden until they receive focus, so they do not change the look of the page. Keyboard users then reach the content without tabbing through every menu item. On a site with a large menu, this saves a lot of key presses. It is a small build task with a big payoff.
A quick keyboard test you can do yourself
You do not need special software for a first check. Automated checkers can sit alongside your other digital marketing tools later. For now, put the mouse aside and load your home page. Then work through these steps.
- Press Tab and see whether a skip link or the first menu item gets a visible outline.
- Keep pressing Tab and check the order follows the layout.
- Open menus, sliders and popups with Enter, Space or the arrow keys.
- Try closing any popup with Escape and check you can move on.
- Watch for focus disappearing behind a sticky header or cookie banner.
- Fill in and send your contact form using only the keyboard.
Write down anything that fails and share it with whoever builds your site. Repeat the test on your most visited pages. Keyboard access is also worth adding to the list of things a website audit should be assessing. Checking it regularly catches problems that creep in with plugin and theme updates.
Frequently asked questions
What does WCAG stand for?
It stands for Web Content Accessibility Guidelines. They are published by the World Wide Web Consortium. The keyboard rules in this article come from WCAG 2.2.
Is it fine to remove focus outlines if they look untidy?
Removing them without a replacement causes problems. WCAG 2.4.7 asks for a visible focus indicator in at least one mode of operation. A custom outline that suits your brand is the better choice.
What is a skip link?
It is a link at the top of a page that jumps straight to the main content. It lets keyboard users skip past the menu on every page. The W3C lists it as one way to meet WCAG 2.4.1.
Do cookie banners cause keyboard problems?
They can. The W3C says a banner fails WCAG 2.4.11 if it entirely hides a component that receives focus. Making the banner modal or using scroll padding are among the fixes it describes.
This is general information about web design. Accessibility standards are updated over time, so check the current W3C guidance for your project.