This website is being built in public and is very much under construction

Accessibility Specialist

How to test keyboard accessibility

Posted

Not everyone can use a mouse or trackpad. Some people can't make precise movements with their hands due to motor impairments, repetitive strain injuries, or temporary limitations. Others simply find the keyboard faster and easier to use. Years ago, I dislocated my shoulder and couldn't use a mouse with my dominant hand. Overnight, I had to rely entirely on my keyboard. It was a humbling experience that showed me just how important good keyboard accessibility really is.

Testing with a keyboard also helps uncover barriers faced by people using assistive technology, like switch controls that mimic keyboard keys, or screen readers that depend on keyboard input to navigate.

The best part? You don't need any special tools to get started - just your keyboard.

Who benefits from keyboard accessibility

Keyboard friendly websites help all sorts of people, including:

  • People who cannot see or have low vision
  • People with physical disabilities who cannot use a mouse
  • People with repetitive strain injuries or chronic pain
  • People with temporary injuries like a broken wrist or fingers
  • People who prefer keyboard-only navigation for efficiency
  • Anyone multi-tasking, like holding a baby with one arm and completing a form using the keyboard with the other

How to test

Essentially, we're testing that everything you can do with a mouse, you can also do with a keyboard, or the same functionaility is available as a keyboard accessible alternative.

  1. Familiarise yourself with the page, its content, components, and interactions
  2. Note the behaviour of any interactive elements, especially any custom or complex components
  3. Check whether any content appears on hover, then confirm that it can also be accessed with the keyboard
  4. Then, using only the keyboard (no mouse, trackpad or other pointing device), navigate the page and perform the following tests
  5. Repeat the tests and 200% and 400% zoom - as responsive layouts can introduce keyboard issues

Basic keyboard navigation

  • Tab: Move forward through interactive elements on the page, like links, buttons and form inputs
  • Shift + Tab: Move backwards through the page
  • Spacebar: Activate buttons, checkboxes and open select dropdowns
  • Enter: Activate links and buttons, submit forms
  • Arrow keys: Navigate through radio buttons, select/dropdowns, sliders, tab panels, auto-complete and tree menus
  • Escape: Close modals, dialogs, menus and popups

Keyboard testing vs. screen reader testing

It's worth noting that keyboard testing and screen reader testing are two distinct separate things with some cross over.

Keyboard-only users move through focusable elements using keys like Tab and Enter. Screen reader users can do all of that, but with extra tools like:

  • Skipping between headings
  • Reading all content, not just focusable items
  • Jumping to specific regions on the page

Keyboard testing is important, but it doesn’t replace screen reader testing. Both are necessary.

What to test

Tip: don't touch the mouse

Avoid using the mouse during keyboard testing - clicks can move the keyboard focus and affect your test results.

1. Check all functionaility works with the keyboard

Anything you can do with a mouse or pointer should also be doable with a keyboard.

Gesture based interactions - like drag-and-drop uploads or pinch-to-zoom maps — aren’t inherently keyboard-friendly. In those cases, there must be an alternative that works with the keyboard (such as an “Upload” button for drag-and-drop uploads, or zoom buttons for maps).

Tests:

  • Tab through the page and check you can reach all interactive elements
  • Use Shift + Tab to go backwards
  • Confirm only interactive elements can be focused (not plain text or headings)
  • Check that anything possible with a pointer is possible with the keyboard, or has an alternative
  • Check links and buttons can be activated with Enter
  • Make sure radio buttons and dropdown options can be selected using arrow keys
  • Confirm forms can be submitted using Enter
  • Check custom widgets (e.g., a <div> made to look like a button) have the same keyboard support as native elements
  • Ensure there are no timing limits on keystrokes - users shouldn’t have to type fast or hold keys down for long periods
  • Check any custom character key shortcuts can be either disabled, remapped or are active only when an element has focus

2. Check focus indicators are highly visible

When you press Tab, can you clearly see which element is focused and will receive input?

Mouse users follow the cursor visually. Keyboard users rely on focus indicators to know where they are and to tell which element will receive keyboard input. These indicators usually appear as an outline or highlight around the focused element.

Examples of different focus indicators can be found in WCAG 1.4.11 Non-text Contrast (AA).

Tests:

  • Every interactive element shows a focus indicator when focused
  • The focus indicator has at least a 3:1 contrast ratio with its adjacent background colour (use the Colour Contrast Analyser tool to check colours)
  • Focus never disappears or skips unexpectedly as you tab through the page
  • Indicators remain visible in alternative colour modes, such as operating system based high contrast modes
  • Ideally, focus indicators are at least as large as the equivalent of a 2 CSS pixel outline around the element

3. Check focus order is logical

Does the tab order make sense? Does it follow the visual and logical reading flow?

Focus should follow the natural reading order, usually left to right, top to bottom (for left-to-right languages like English).

Watch out for unexpected jumps or skipped content. If you're sighted, it should be obvious which element is next - if focus jumps somewhere else, it could confuse users. For example, if expanding an accordion reveals new content, that content should either come next in the tab order or receive focus programmatically if it's inserted earlier in the DOM.

Some tools, like Accessibility Insights can help by visually mapping the tab order as you move through the page.

Screenshot of Accessibility Insights with the show tab stops tool enabled. The order of focused elements is overlayed on the screen showing the tab stop order of the links in the header.

Tests:

  • Tab through the page and confirm the focus sequence matches the intended reading order
  • Open menus or modals to check how focus is handled - it should move inside, and return to the trigger when closed
  • Check that content revealed by a user action fits cleanly into the focus order or gets focus automatically

4. Check focused elements are not hidden

If a focused element is hidden behind something like a sticky header, cookie banner, or chat widget, users won’t know where they are or what will receive keyboard input.

Also watch for elements that are still focusable when visually hidden — for example, collapsed accordion panels or navigation items that should not be focusable until expanded.

Tip: use a bookmarklet to find hidden tab stops

Sometimes it can be difficult to tell which hidden element is gaining keyboard focus. I created the Log Focus bookmarklet to help with this. Drag or save the "Log Focus" link to your bookmarks. Then when testing, click it and tab through the page. It will output the accessible name, element and XPATH of each element you focus, to the DevTools JavaScript console. This can help identify which element has focus when you spot a hidden tab stop or an element fully obscured by another element.

Tests:

  • Ensure focused elements are at least partially visible (ideally fully visible)
  • Check sticky or floating elements don’t completely obscure focused elements
  • User movable content (e.g., a repositionable dialog) can block focus after a user has moved it, but not in it's initial position

5. Check focus is never trapped

Users should always be able to move focus away from a widget or area unless it's designed to trap focus (e.g., inside a modal) with a clear and accessible exit (like a close button).

Test:

Check you can navigate through the full page without focus getting trapped or stuck in a certain area (unless an exit method is available).

6. Check the page has a working skip link

Skip links let users jump straight to the main content, avoiding having to navigate through content repeated on each page, like navigation. They usually appear only when focused.

Screenshot of the W3C website, showing a focused skip to content link

Tests:

  • The first tab stop should be a “Skip to main content” link (you may need to dismiss a cookie banner first)
  • Activating it should move focus directly to the main page content, not just visually scroll

7. Check focus is contained within modals and popups

When a modal dialog opens, focus should move inside it and loop through its contents until closed. Users shouldn't have to tab through the entire background page to reach the modal, nor should they be able to tab out of the modal to the background page. When the modal closes, focus should return to the button or element that opened it.

Tests:

  • Check focus is moved inside of a modal when opened
  • Check focus loops within the modal using Tab and Shift + Tab
  • Confirm that background content cannot be navigated to while the modal is open

8. Check focus does not trigger actions by itself

Simply focusing an element should not activate it or trigger anything unexpected. Actions should only occur when the user explicitly activates an element using keys like Enter or Space.

Tests

Check that focusing an element does not:

  • submit a form
  • open a new tab or window
  • reload the page
  • auto-activate activate a button or link

Final thoughts

Next time you review a page, put the mouse aside and try navigating with just your keyboard. You’ll quickly see how usable (or not) the experience really is. Fixing these issues benefits a wide range of people and makes a more accessible web for everyone.