Making Your HubSpot Website WCAG 2.1 Compliant

2.1.2 No Keyboard Trap

MCS Accessibility Team

MCS Accessibility Team
Last Updated July 23, 2020

The following directions are part of a full step-by-step guide to making a HubSpot website WCAG 2.1 AA compliant. These recommendations are intended for websites managed on the HubSpot CMS but can be adapted for other content management systems. In addition to explaining the WCAG Success Criteria and how to address them, this guide also describes how the AudioEye Managed solution may address each issue.

LEVELA
Success Criteria

2.1.2 No Keyboard Trap

  • Resolved
  • Partially Resolved
  • Manually Managed
  • N/A - Level AAA
Principle: Operable
User interface components and navigation must be operable.
Guideline: Keyboard Accessible
Make all functionality available from a keyboard.

If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

Note 1: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

View Official WCAG 2.1 Compliance Techniques

  • This criteria is partially resolved and/or detected with AudioEye Managed but may require some manual intervention and/or collaboration with AudioEye.

Understanding 2.1.2 No Keyboard Trap

Users with certain disabilities do not rely on a mouse to use their devices but control all aspects of their web browsing through the keyboard. Through the use of various keys, they are able to navigate websites much like one would with a mouse.

Common keys used for keyboard-exclusive navigation include:

  • Arrow Keys: Up and Down Arrows are typically used for scrolling a page, and in some instances menu lists. Right and Left can be used for horizontal scrolling when necessary and can also be used, in certain cases, to adjust sliders or move between menu categories.
  • Tab: This is used to navigate through each item on the page. Every time a user clicks the Tab key, an individual section of the page is highlighted in descending order from the items at the top of the page down to the bottom. This includes all navigation items, links, headers, paragraphs, and forms. Once the bottom of the page is reached, one more click of the Tab key will bring the user back to the first highlightable prompt. To move in reverse, Shift+Tab may be used.
  • Enter: The Enter key is used to select items. Often used in conjunction with the Tab key, when an item is highlighted, the Enter key may then be used to interact with that item, including opening a link or submitting a form.
  • Space: The Space bar can be used to select or deselect form selection items such as checkboxes and radio buttons.
  • Esc: This key is used to escape items that appear above the primary content of the page. This includes pop-up messages and modals as well as drop-down menus. A user may use Tab or Arrow keys to peruse these items. In order to end the interaction without selecting anything and to return to the main display, the Esc key is used.


Now that you have a deeper understanding of keyboard shortcuts, let's discuss situations what 2.1.2 No Keyboard Trap looks to prevent.

Understanding Keyboard Traps

For a user to be able to successfully navigate a website using only their keyboard, the functionalities listed above must have the ability to be used. For basic website features such as drop-down navigation, links, and paragraphs, this is not a problem. 

The problem comes along when multiple formats are used in tandem on a page. Uses of certain modules, plug-ins or embedded items can result in a situation where if a keyboard-only user enters this feature, there is no method of escape. The user is trapped. In cases where a user gets trapped, their only choice is to exit the browser completely and begin their browsing anew. Chances are, they will never be able to access any content below this plug-in or embedded item as they do not have the means to get through.

If there are items used on a webpage that are not accessibility supported, or if they are accessible but used in a non-conforming way, they must not prevent the user from being able to interact with the remainder of the page. 

In cases where the standard keys cannot be used to exit the module, this criterion requires the user be advised of the method they need to use to exit. 

Note: While non-accessible modules may be used on a website as long as it is not a Keyboard Trap, in order to be compliant, the information this module provides must still be available using accessibly-supported means.

How AudioEye Helps

AudioEye conducts manual usability testing to ensure keyboard traps have been avoided and nothing inhibits full keyboard interaction between the various elements on a page. If keyboard traps are found, in most cases, AudioEye will manually remediate them and may notify the Managed customer about the issue, how it was resolved, and how to resolve the issue at source.

Solutions

First and foremost, ensure that all components of your website have the ability to be interacted with solely through the use of a keyboard. 

If there are any items that require the use of keystrokes not typically used to interact with, or exit from said item, accessible instructions must be provided to inform the user of how to do so.

For more information, please visit the official W3C article: Understanding 2.1.2 No Keyboard Trap


Download the WCAG 2.1 Compliance Checklist

What to expect if you download this checklist

Video: What to Expect If You Download this Checklist

Checklist Download

Questions?

Let us know if we can help you address this specific WCAG Recommendation.

Recent Morey Creative Studios Blog Articles