All functionality of the content is operable through a keyboard interface
Introduction
This document gives information about the related accessibility checks:
All functionality of the content is operable through a keyboard interface.
What
All functions on the page must work by using a keyboard and without requiring the user to time their keystrokes.
Notes
This can be a physical keyboard connected to the computer or a keyboard-like interface, such as a virtual on-screen keyboard.
Timing keystrokes means the user should not have to press specific keys within a time limit to complete an action.
Why
It is vital for people with mobility impairments that website owners ensure that all content and functionality on a webpage can be operated with a keyboard. Many in this group cannot use a mouse or trackpad due to challenges with fine motor skills or eye-hand coordination. Instead, they rely on assistive technologies like speech input software, sip-and-puff devices, on-screen keyboards, and scanning software to navigate and interact with web content. These tools act as keyboard emulators, and provide alternative ways for them to operate websites, and ensures that they have access to critical functionality. Without proper keyboard support, users with mobility impairments may be entirely excluded from engaging with online content.
Additionally, keyboard operability benefits blind and low-vision users who often cannot see or track a pointer on the screen. Screen readers and braille displays are optimized for keyboard input, which enables these users to interact with content in a logical sequence. Similarly, individuals with low vision may find keyboard navigation more efficient and less visually demanding than relying on a mouse. When you ensure full keyboard accessibility, websites become inclusive for a broad range of users, including both those with mobility impairments and those with visual disabilities.
This check affects the following users who have:
Mobility impairments: Who navigate the page using keyboard or alternative input devices.
Blindness or vision impairments: Who navigate websites with keyboard commands to screen reader software.
User story
Sandra is 38 years old. At the age of 16, her life took an unexpected turn during a sports accident on the basketball court. While attempting a daring dunk, she landed in an awkward manner, resulting in a spinal cord injury. Unfortunately, this event left her paralyzed from the waist down.
"As someone who relies on dictation software to get through my day, it is super frustrating when I hit a wall with certain booking systems. The calendar picker? Forget it. It is like the software does not even recognize it as something I can interact with. I will say ‘click’ a hundred times, and nothing happens. So, I am forced to grab the mouse, which might not sound like a big deal, but on my bad days? Every little movement hurts. It turns a simple task like scheduling an appointment into this painful, drawn-out ordeal. I just want to be able to do things on my own terms, without unnecessary barriers."
Examples
This section gives some examples of the issue.
Example: Inaccessible social media buttons
A series of icons for following a company on social media is implemented as <div> elements that cannot receive keyboard focus.
The use of <div> elements, which cannot receive keyboard focus, makes the functionality of the icons inaccessible to users who rely on keyboard navigation.
Example: Accessible social media buttons
A series of icons for following a company on social media is implemented as <a> elements, which support keyboard focus by default.
<a href="https://www.linkedin.com" target="_blank" style="display: inline-block; width: 40px; height: 40px; background-image: url('linkedin-icon.png'); background-size: cover; margin: 5px;" aria-label="Follow us on LinkedIn"></a>
<a href="https://www.youtube.com" target="_blank" style="display: inline-block; width: 40px; height: 40px; background-image: url('youtube-icon.png'); background-size: cover; margin: 5px;" aria-label="Follow us on YouTube"></a>
<a href="https://www.x.com" target="_blank" style="display: inline-block; width: 40px; height: 40px; background-image: url('x-icon.png'); background-size: cover; margin: 5px;" aria-label="Follow us on X"></a>
The use of `<a>` elements, which by default can receive keyboard focus, ensures that users who rely on keyboard navigation can also navigate to and activate the icons' functionality.
How
How to review it.
The Web Governance platform highlights all pages for keyboard review.
Your task is to review all interactive elements on the page and ensure that they can be operated with the keyboard. Examine the page to identify all interactive elements such as links, buttons, menus, dropdown lists, and anything else you can interact with by using a mouse. Once you have listed all interactive functionality, test whether each element can be accessed and operated by using only the keyboard.
Use the Tab key to move forward through the interactive elements on the page, and Shift + Tab to move backward. For more complex components, such as groups of radio buttons, dropdown menus, or date pickers, you may need to use the arrow keys to navigate or select values within those components. Typically, you will use the Spacebar or Enter key to activate an element, such as a link or button.
Unfortunately, there are no strict rules for how keyboard navigation should work in every case. However, using the key combinations mentioned above, you should be able to navigate the page and test all functionalities.
If you can focus on and operate all elements on the page, you can mark it as "reviewed."
For instructions on how to set an issue to "reviewed" with Web Governance, see the user guide article:
It is not a requirement for every button or interactive element to be operable by a keyboard if you provide an alternative way to perform the same function with the keyboard. For example, a drag-and-drop file upload feature does not need to be directly keyboard accessible if there is a nearby button that allows users to upload files and can be operated with the keyboard.
There are a few exceptions for tasks that rely on path-based input, such as freehand drawing or painting. These actions cannot be effectively controlled with a keyboard without an unreasonable number of keystrokes. However, tasks like drawing straight lines, resizing windows, or dragging objects (where the path does not matter) should still be accessible by keyboard.
All functionality of the content is operable through a keyboard interface
All functionality of the content is operable through a keyboard interface
Introduction
This document gives information about the related accessibility checks:
All functionality of the content is operable through a keyboard interface.
What
All functions on the page must work by using a keyboard and without requiring the user to time their keystrokes.
Notes
This can be a physical keyboard connected to the computer or a keyboard-like interface, such as a virtual on-screen keyboard.
Timing keystrokes means the user should not have to press specific keys within a time limit to complete an action.
Why
It is vital for people with mobility impairments that website owners ensure that all content and functionality on a webpage can be operated with a keyboard. Many in this group cannot use a mouse or trackpad due to challenges with fine motor skills or eye-hand coordination. Instead, they rely on assistive technologies like speech input software, sip-and-puff devices, on-screen keyboards, and scanning software to navigate and interact with web content. These tools act as keyboard emulators, and provide alternative ways for them to operate websites, and ensures that they have access to critical functionality. Without proper keyboard support, users with mobility impairments may be entirely excluded from engaging with online content.
Additionally, keyboard operability benefits blind and low-vision users who often cannot see or track a pointer on the screen. Screen readers and braille displays are optimized for keyboard input, which enables these users to interact with content in a logical sequence. Similarly, individuals with low vision may find keyboard navigation more efficient and less visually demanding than relying on a mouse. When you ensure full keyboard accessibility, websites become inclusive for a broad range of users, including both those with mobility impairments and those with visual disabilities.
This check affects the following users who have:
Mobility impairments: Who navigate the page using keyboard or alternative input devices.
Blindness or vision impairments: Who navigate websites with keyboard commands to screen reader software.
User story
Sandra is 38 years old. At the age of 16, her life took an unexpected turn during a sports accident on the basketball court. While attempting a daring dunk, she landed in an awkward manner, resulting in a spinal cord injury. Unfortunately, this event left her paralyzed from the waist down.
"As someone who relies on dictation software to get through my day, it is super frustrating when I hit a wall with certain booking systems. The calendar picker? Forget it. It is like the software does not even recognize it as something I can interact with. I will say ‘click’ a hundred times, and nothing happens. So, I am forced to grab the mouse, which might not sound like a big deal, but on my bad days? Every little movement hurts. It turns a simple task like scheduling an appointment into this painful, drawn-out ordeal. I just want to be able to do things on my own terms, without unnecessary barriers."
Examples
This section gives some examples of the issue.
Example: Inaccessible social media buttons
A series of icons for following a company on social media is implemented as <div> elements that cannot receive keyboard focus.
The use of <div> elements, which cannot receive keyboard focus, makes the functionality of the icons inaccessible to users who rely on keyboard navigation.
Example: Accessible social media buttons
A series of icons for following a company on social media is implemented as <a> elements, which support keyboard focus by default.
<a href="https://www.linkedin.com" target="_blank" style="display: inline-block; width: 40px; height: 40px; background-image: url('linkedin-icon.png'); background-size: cover; margin: 5px;" aria-label="Follow us on LinkedIn"></a>
<a href="https://www.youtube.com" target="_blank" style="display: inline-block; width: 40px; height: 40px; background-image: url('youtube-icon.png'); background-size: cover; margin: 5px;" aria-label="Follow us on YouTube"></a>
<a href="https://www.x.com" target="_blank" style="display: inline-block; width: 40px; height: 40px; background-image: url('x-icon.png'); background-size: cover; margin: 5px;" aria-label="Follow us on X"></a>
The use of `<a>` elements, which by default can receive keyboard focus, ensures that users who rely on keyboard navigation can also navigate to and activate the icons' functionality.
How
How to review it.
The Web Governance platform highlights all pages for keyboard review.
Your task is to review all interactive elements on the page and ensure that they can be operated with the keyboard. Examine the page to identify all interactive elements such as links, buttons, menus, dropdown lists, and anything else you can interact with by using a mouse. Once you have listed all interactive functionality, test whether each element can be accessed and operated by using only the keyboard.
Use the Tab key to move forward through the interactive elements on the page, and Shift + Tab to move backward. For more complex components, such as groups of radio buttons, dropdown menus, or date pickers, you may need to use the arrow keys to navigate or select values within those components. Typically, you will use the Spacebar or Enter key to activate an element, such as a link or button.
Unfortunately, there are no strict rules for how keyboard navigation should work in every case. However, using the key combinations mentioned above, you should be able to navigate the page and test all functionalities.
If you can focus on and operate all elements on the page, you can mark it as "reviewed."
For instructions on how to set an issue to "reviewed" with Web Governance, see the user guide article:
It is not a requirement for every button or interactive element to be operable by a keyboard if you provide an alternative way to perform the same function with the keyboard. For example, a drag-and-drop file upload feature does not need to be directly keyboard accessible if there is a nearby button that allows users to upload files and can be operated with the keyboard.
There are a few exceptions for tasks that rely on path-based input, such as freehand drawing or painting. These actions cannot be effectively controlled with a keyboard without an unreasonable number of keystrokes. However, tasks like drawing straight lines, resizing windows, or dragging objects (where the path does not matter) should still be accessible by keyboard.
Web Governance