This document provides information about the Acquia Web Governance accessibility check:
Can all functionality be operated with keyboard?
What
All functions on the page must work with a keyboard and must not require that the user times 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.
Who
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 provides some examples of the issue.
Example: Inaccessible social media buttons
A series of icons that allow users to follow a company on social media is implemented as <div> elements, which 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 that allow users to follow 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 icon functionality.
How
This section provides information about how to identify and review the issue.
How to identify it
The Web Governanceplatform highlights all pages for keyboard review.
How to review it
You must review all interactive elements on the page and ensure that they can be operated with the keyboard.
1. Examine the page to identify all interactive elements such as links, buttons, menus, dropdown lists, and anything else you can use with a mouse.
2. Test whether each element can be accessed and operated with 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, with 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.
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 that require the user to draw straight lines, resize windows, or drag objects (where the path does not matter) should still be accessible by keyboard.
This document provides information about the Acquia Web Governance accessibility check:
Can all functionality be operated with keyboard?
What
All functions on the page must work with a keyboard and must not require that the user times 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.
Who
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 provides some examples of the issue.
Example: Inaccessible social media buttons
A series of icons that allow users to follow a company on social media is implemented as <div> elements, which 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 that allow users to follow 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 icon functionality.
How
This section provides information about how to identify and review the issue.
How to identify it
The Web Governanceplatform highlights all pages for keyboard review.
How to review it
You must review all interactive elements on the page and ensure that they can be operated with the keyboard.
1. Examine the page to identify all interactive elements such as links, buttons, menus, dropdown lists, and anything else you can use with a mouse.
2. Test whether each element can be accessed and operated with 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, with 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.
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 that require the user to draw straight lines, resize windows, or drag objects (where the path does not matter) should still be accessible by keyboard.
Web Governance