Motivation
Accessible design has become increasingly important to our global customers, especially for those customers who come from countries where laws regulate the level of Accessibility required to meet basic conformance. One basic requirement is that websites or applications are fully accessible by keyboard navigation. Accessibility is not limited to keyboard input alone but encompasses all other input methods – mouse, voice, etc. For first-time Accessibility testers, keyboard navigation is the easiest place from which to start their testing journey
Introduction
In today’s digital world, creating accessible applications is essential not only for meeting legal requirements but also for enhancing user satisfaction. Ensuring that keyboard navigation is smooth and intuitive is a key part of this process, especially for users with disabilities. In this guide, we’ll explore how to effectively test keyboard navigation for accessibility on desktop devices.
Proper keyboard navigation ensures that:
Focused elements are clearly highlighted.
Navigation follows a logical order.
Non-essential elements are skipped.
This article explores what keyboard accessibility means and provides guidelines for effective testing.
Mechanics of keyboard navigation accessibility testing on Windows 10 and Mac devices
Once the testing environment is loaded, it’s essential to test not only the basic keyboard navigation (TAB) but also ensure that each interactive element—such as buttons, links, and input fields—works smoothly with other common keyboard commands (Enter, Space, Shift+TAB). This comprehensive testing will help you confirm that the application is fully navigable by users with motor disabilities or those who rely on keyboard controls.
The keys mentioned above are not the only ones you can use while testing the Keyboard Navigation. You can find a detailed list of keyboard keys below:
Key Combination | Function | Windows | Mac Equivalent | Comment |
Tab | Navigate through elements | ✅ | ✅ | Moves focus to the next interactive element |
Shift + Tab | Reverse navigation | ✅ | ✅ | Moves focus back to the previous interactive element |
Enter | Activate selected element | ✅ | ✅ | Triggers button clicks, link navigation, and form submissions |
Spacebar | Toggle checkboxes, control media | ✅ | ✅ | Used to activate checkboxes and play/pause media content |
Arrow Keys | Navigate within controls | ✅ | ✅ | Moves focus within menus, dropdowns, and sliders |
Escape | Exit an element | ✅ | ✅ | Closes modals, dropdowns, and other interactive elements |
Home | Jump to top of the page | ✅ |
| Moves focus to the first element or top of the page |
End | Jump to the bottom of the page | ✅ |
| Moves focus to the last element or bottom of the page |
Page Up | Increase slider value by 10% | ✅ |
| Moves up a section or increases slider values |
Page Down | Decrease slider value by 10% | ✅ |
| Moves down a section or decreases slider values |
Note: Remember that when reporting Keyboard Navigation Accessibility bugs, you are not allowed to record the sound in the screencast.
Note: When testing on Windows 10, use the built-in On-Screen Keyboard app to simulate a keyboard experience and capture accurate screencasts. To quickly open the On-Screen Keyboard on your Windows 10 device simultaneously press Win+CTRL+O keys on your physical keyboard.
For Mac users, the Accessibility Keyboard feature, accessed via the keyboard shortcut Option+Command+F5, will allow you to test keyboard navigation on the screen.
Understanding WCAG 2.1 and 2.2
The Web Content Accessibility Guidelines (WCAG) are internationally recognized standards developed to ensure digital content is accessible to all users, including people with disabilities. These guidelines are continuously updated to reflect new best practices and technologies.
WCAG 2.1 (published in 2018) extended WCAG 2.0 to address accessibility for users with vision impairments, mobile users, and people with cognitive disabilities.
WCAG 2.2 (published in 2023) builds on WCAG 2.1 and introduces additional criteria to support users with motor disabilities, improve keyboard navigation, and enhance focus visibility.
Each version is backward-compatible, meaning WCAG 2.2 includes all the criteria from 2.1, plus additional enhancements. Some organizations may still reference WCAG 2.1 due to current legal or policy standards, but WCAG 2.2 is the most up-to-date version and should be prioritized during accessibility testing and development.
WCAG 2.1 Quick Reference Guide
WCAG 2.2 Quick Reference Guide
In the following sections, we will highlight the most commonly used and practical success criteria from WCAG 2.1 and 2.2, focusing on those relevant for keyboard accessibility testing.
WCAG 2.1 Keyboard accessibility checkpoint
Before we focus on the success criteria related to the Keyboard Navigation, we need to remind you that our platform runs tests for A and AA levels of Accessibility conformance. Level AAA of Accessibility conformance is not in the scope of Test IO Accessibility testing.
There are 4 success criteria related to the Keyboard Navigation that should be met to ensure that the customer’s environment is accessible for all users: 2.1.1., 2.1.2., 2.1.3, and 2.1.4. As 2.1.3. belongs to the AAA level of conformance, we will not include it in our analysis.
To ensure full keyboard accessibility, web content should meet the following WCAG 2.1 success criteria at Level A:
2.1.1 Keyboard Accessibility – All interactive elements must be operable via keyboard without requiring a mouse.
2.1.2 No Keyboard Trap – Users should be able to navigate through elements using
TabandShift + Tabwithout getting stuck.2.1.4 Character Key Shortcuts – Single-key shortcuts should be either disabled, remappable, or active only when focused.
2.4.7 Focus Visible – The visual focus indicator must be clearly visible to help users navigate the interface effectively.
Failure to meet these criteria results in critical accessibility issues that hinder navigation for users relying on keyboards.
WCAG 2.2 Keyboard accessibility checkpoints
The following Level A and AA criteria introduced in WCAG 2.2 are particularly relevant when evaluating keyboard accessibility (excluding AAA-level criteria):
2.4.11 Focus Not Obscured (Minimum) (Level AA): Ensures that the visible keyboard focus is not hidden behind fixed headers, footers, or other overlapping content.
2.4.13 Focus Appearance (Level AA): Focus indicators must be clearly visible, with sufficient contrast and size, so users can easily identify where the focus is.
2.5.7 Dragging Movements (Level AA): Functionality requiring dragging must offer a keyboard-accessible alternative (e.g., using arrow keys or Enter).
2.5.8 Target Size (Minimum) (Level AA): Ensures that interactive targets (e.g., buttons, links) are large enough to be easily selected using a pointer or keyboard.
These success criteria complement the existing WCAG 2.1 requirements and help ensure a more robust and inclusive keyboard experience.
Methods and tips for testing keyboard accessibility (WCAG 2.1 & 2.2)
Web Content Accessibility Guidelines (WCAG) 2.1 and 2.2 emphasize the importance of keyboard accessibility. While each version contains specific success criteria, many of the testing methods remain consistent across both. The following practical tips and techniques are essential when evaluating keyboard navigation:
1. All Functionality is Navigable via Keyboard
Ensure all mouse-dependent functionality (e.g., hover actions, click events) is also accessible via keyboard. For example, a submenu that opens on hover should also open when the element receives focus and Enter is pressed.
Test:
Navigate through all elements using the keyboard.
Confirm all interactive elements are accessible without a mouse.
2. No Keyboard Trap
Users must be able to freely navigate through content and exit any section without being trapped (especially in modals or pop-ups).
Test:
Ensure modals, dialogs, and widgets allow the user to exit using
Escor other keyboard shortcuts.Verify that Tab and Shift+Tab move the focus both forward and backward.
3. Logical Tab Order
Focus should follow the visual and logical structure of the page to prevent confusion or disorientation.
Test:
Use Tab to move through elements and ensure the sequence makes sense.
Ensure content like menus, forms, and buttons follow a predictable order.
4. Focus Visibility
Clearly indicate which element currently has focus. This helps users understand where they are during navigation.
Test:
Ensure the focus indicator is always visible and not removed by custom styles.
Check all focusable elements (buttons, links, inputs) for visible outlines or borders on focus.
5. Keyboard-Accessible Event Handlers
All functionality triggered by mouse (click, drag-and-drop, hover) must have an equivalent keyboard method.
Test:
Ensure buttons and links can be activated with
EnterorSpace.Test drag-and-drop or carousel features using arrow keys or other accessible alternatives.
A good example of a bug report:
Title: [AA] [2.4.7] Keyboard focus does not visible around "Submit" button in the "JOIN OUR MAILING LIST" form in the "Contact” page
Steps:
Go to https://www.dummy.com/
Click the "Contact" link in the header
Press "Tab" key to navigate through "JOIN OUR MAILING LIST" form fields
Actual Result: Focus is missing around the "Submit" button after navigate through "JOIN OUR MAILING LIST" form fields.
Failed WCAG 2.1 checkpoint(s): 2.4.7 Level AA
Expected Result: Focus should land on the "Submit" button in the "JOIN OUR MAILING LIST" form
Note: Here you need to bear in mind that as in any test on our platform, you need to be careful not to submit a duplicated bug.
Conclusion
Keyboard accessibility is a crucial aspect of inclusive web design that ensures users with disabilities, as well as those who prefer keyboard navigation, can interact with applications seamlessly. By regularly testing your application using keyboard navigation, you ensure that all interactive elements are accessible without a mouse, meeting WCAG standards and improving the overall user experience.