This document provides information about the Acquia Web Governance accessibility checks:
Is keyboard focus trapped in any component?
What
Keyboard focus must never be trapped on a specific component of the website. Users who navigate with a keyboard or similar interfaces must always be able to close or move away from the current component with common key presses.
Why
If users who navigate with a keyboard encounter a component they cannot move away from, they can become stuck and unable to continue to interact with the website. This creates a frustrating and limiting experience, especially for users who rely solely on keyboard navigation because of mobility impairments or the use of assistive devices. Ensure that all components allow easy navigation out of them with standard key presses like Tab or Esc is essential to maintaining a seamless and accessible browsing experience.
Who
This check affects the following users who have:
Mobility impairments: Who navigate the page with a 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.
"I swear, sometimes I feel like I’m being held hostage on these websites. I use dictation software, which works kind of like a keyboard. I just say ‘Tab, Tab, Tab,’ and it moves through the page. But man, when I am looking for new exercise ideas, I will come across video players that open in fullscreen, and I am stuck. I can tab between play, pause, and all those buttons, but closing the damn window? Forget about it. Feels like they are doing it on purpose, trying to force me to watch their whole video. It is infuriating."
Examples
This section provides some examples of the issue.
Example: Modal dialog with keyboard trap
On a flight-booking page, the user has forgotten to enter their passport number. A status message is displayed in an overlay on the page. The dialog box that contains the status message receives keyboard focus, and it must be closed before the user can continue to interact with the page. However, the "close" button is not coded as a focusable button, which means that it can only be activated with a mouse-click.
<div class="modal" role="dialog" aria-labelledby="modal-title" aria-describedby="modal-description">
<div class="close" onclick="closeModal()">X</div>
<h2 id="modal-title">Error</h2>
<p id="modal-description">You must fill in your passport number.</p>
</div>
Because the user cannot interact with anything else on the page until the overlay is closed, and since it cannot be closed with the keyboard, users who rely on keyboard navigation are trapped and unable to proceed.
How
This section provides information about how to identify and review the issue.
How to identify it
The Acquia Web Governanceplatform highlights all pages for keyboard review.
How to review it
Review the page with keyboard navigation to ensure you do not get trapped anywhere on the page.
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 can 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 situation. With the key combinations mentioned above, you should be able to navigate through the page and test for any keyboard traps.
Review all of the interactive elements on the page with the keyboard and ensure you do not get stuck anywhere. Pay special attention to elements that open and close or appear in overlays on top of other content.
If you do not encounter any keyboard traps, meaning you can navigate away from all components with the keyboard, you can mark this issue as Reviewed.
This document provides information about the Acquia Web Governance accessibility checks:
Is keyboard focus trapped in any component?
What
Keyboard focus must never be trapped on a specific component of the website. Users who navigate with a keyboard or similar interfaces must always be able to close or move away from the current component with common key presses.
Why
If users who navigate with a keyboard encounter a component they cannot move away from, they can become stuck and unable to continue to interact with the website. This creates a frustrating and limiting experience, especially for users who rely solely on keyboard navigation because of mobility impairments or the use of assistive devices. Ensure that all components allow easy navigation out of them with standard key presses like Tab or Esc is essential to maintaining a seamless and accessible browsing experience.
Who
This check affects the following users who have:
Mobility impairments: Who navigate the page with a 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.
"I swear, sometimes I feel like I’m being held hostage on these websites. I use dictation software, which works kind of like a keyboard. I just say ‘Tab, Tab, Tab,’ and it moves through the page. But man, when I am looking for new exercise ideas, I will come across video players that open in fullscreen, and I am stuck. I can tab between play, pause, and all those buttons, but closing the damn window? Forget about it. Feels like they are doing it on purpose, trying to force me to watch their whole video. It is infuriating."
Examples
This section provides some examples of the issue.
Example: Modal dialog with keyboard trap
On a flight-booking page, the user has forgotten to enter their passport number. A status message is displayed in an overlay on the page. The dialog box that contains the status message receives keyboard focus, and it must be closed before the user can continue to interact with the page. However, the "close" button is not coded as a focusable button, which means that it can only be activated with a mouse-click.
<div class="modal" role="dialog" aria-labelledby="modal-title" aria-describedby="modal-description">
<div class="close" onclick="closeModal()">X</div>
<h2 id="modal-title">Error</h2>
<p id="modal-description">You must fill in your passport number.</p>
</div>
Because the user cannot interact with anything else on the page until the overlay is closed, and since it cannot be closed with the keyboard, users who rely on keyboard navigation are trapped and unable to proceed.
How
This section provides information about how to identify and review the issue.
How to identify it
The Acquia Web Governanceplatform highlights all pages for keyboard review.
How to review it
Review the page with keyboard navigation to ensure you do not get trapped anywhere on the page.
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 can 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 situation. With the key combinations mentioned above, you should be able to navigate through the page and test for any keyboard traps.
Review all of the interactive elements on the page with the keyboard and ensure you do not get stuck anywhere. Pay special attention to elements that open and close or appear in overlays on top of other content.
If you do not encounter any keyboard traps, meaning you can navigate away from all components with the keyboard, you can mark this issue as Reviewed.
Web Governance