Keyboard Testing
Welcome to Part 7 of our “First Steps to An Accessible Website” blog series! This post is focused on an often-overlooked critical part of an accessible website – keyboard support!
Keyboard accessibility is something automated accessibility scanning tools rarely, if ever, can fully verify. While accessibility overlays may have features to enhance keyboard support where it is lacking, these overlays do not address everything, and the user experience is typically not seamless.
The ability to navigate content and interact with controls using only the keyboard is something that can have a major impact on many users and assistive technologies. Most web design, development, and testing fail to think about the keyboard…even when efforts have been made to create accessible content. This is because the focus of interaction with the page content is by using a mouse for pointing and clicking.
The lack of keyboard consideration during the web development lifecycle means that many blocking issues can be left unchecked even when a scanning tool provides a “clean” report. Yet, keyboard testing is one of the simplest accessibility tests that can be performed. It doesn’t require any special testing tools and requires little training to perform properly.
Our goal with this post is to help identify some keyboard testing that you can perform on your own and to better understand what to look for as part of the testing process. Being able to identify keyboard issues will help in fixing existing issues and creating designs that take consider the keyboard-only user experience.
We will focus on three critical areas for keyboard testing. They are:
- Interactive Elements
- Visible Indication of Focus
- Change of Context
What we cover in this post is not a complete resource for keyboard accessibility but does cover some of the basic issues that can impact users on a desktop environment. The examples provided do not lend themselves to mobile devices.
Let’s get started!
Interactive Elements
Almost every webpage contains content that can be invoked or manipulated to complete a specific action. Such as a hyperlink to navigate to another page, a set of form fields to fill out and submit data, expandable/collapsible sections in an FAQ, toggle switches, calendar widgets, filter controls, etc. While these almost always work with a mouse, keyboard support for interactive elements can easily be overlooked because of the rush to get content published.
Using the keyboard to verify and validate keyboard support on a web page is not difficult. It is simply a process of using the TAB key to navigate through the page and ensure that all interactive content receives keyboard focus, and that the keyboard can be used to successfully manipulate the controls and complete an action without resorting to using the mouse.
The following examples will help demonstrate what is meant by providing keyboard support to interactive elements.
Toggle with Keyboard and Mouse Support
In this example both mouse and keyboard support are provided. You can toggle the switch to an “on” or “off” state using the mouse and by using the keyboard to tab to the control then pressing the enter or spacebar keys to toggle the switch. Try accessing and toggling the switch using both the mouse and the keyboard.
Toggle with Keyboard and Mouse Support Example:
Toggle without Keyboard Support
This example toggle switch provides mouse support but lacks support for the keyboard. While the control accepts the keyboard focus, the keyboard cannot be used to toggle the switch between “on” and “off”. A keyboard-only user would be blocked from interacting with this toggle control. Try accessing and toggling the switch using both the mouse and the keyboard to see for yourself.
Toggle without Keyboard Support Example:
Toggle without Keyboard Focus
The next example toggle switch still provides support for the mouse, yet it does not accept keyboard focus and therefore the keyboard-only user will be blocked from toggling the state to a different setting. Try accessing and toggling the switch using the mouse and then try setting the keyboard focus to the control using the TAB key. I bet you won’t be able to do it!
Toggle without Keyboard Focus Example:
This line of text after the switch is set to receive keyboard focus so that you can see that trying to tab to the above toggle doesn’t happen and instead the keyboard focus lands on the next keyboard focusable content, in this case the paragraph. Try using SHIFT+TAB to tab backwards to the control. Still bet you can’t set keyboard focus to it!
Accessibility Includes Keyboard Support
While we used a toggle control for the examples in this section, the principles apply to all interactive controls, be it an out-of-the-box HTML control or a customized widget.
In almost all cases, an element that is interactive with the mouse should also fully support being interactive with the keyboard. As you tab through a page, verify that all controls that can be activated with a mouse can also receive keyboard focus and be successfully manipulated using only the keyboard. If any control does not allow this, you likely have a blocking accessibility issue.
Visible Indication of Focus
Even when elements can receive keyboard focus and be manipulated using only the keyboard, sometimes the visual indication of where the keyboard input focus is on the page is missing. This is also an accessibility issue.
For a visual user to know where the current keyboard input focus is on the page, there must be some visual indication of that focus. This can take several forms depending on the type of element with focus. For example, an input field may only have a flashing cursor to indicate it has focus. Although it is generally a good idea to provide more obvious visual indication such as a thicker border and change of color within the input field.
Browsers, by default, will provide a visual indication of focus for elements that receive keyboard focus. This varies from browser to browser and does not guarantee an accessible experience.
Default Visual Indication of Focus
In this example, using the keyboard to TAB through the form controls will use your browser's default for visually identifying which control has the current keyboard input focus. Viewing the same example in a different browser will likely provide a difference experience, for example Chrome vs Firefox.
Tab through the form below and take note of the default visual indication of focus provided for each control.
Default Visual Indication of Focus Example:
No Visual Indication of Focus
Often, the default visual focus may be overridden which can make it difficult and sometimes impossible for a keyboard only user to know which control has the focus.
In the following example, using the keyboard to tab through the control will only show the flashing cursor in the text fields when they have focus and will provide no visual indication of focus for the buttons.
No Visual Indication of Focus Example:
Enhanced Visual Indication of Focus
Hopefully you can see that deliberately disabling the visual indication of keyboard focus is not beneficial or accessible for keyboard only users. Relying on the browser default can also be problematic as browsers vary in how visual focus is indicated and do not take into account the colors used which can hide the visual indication of focus. It is recommended that designers take consider the keyboard user experience and assign how that experience should occur so that developers can code accordingly to ensure an accessible experience.
In the following example, you will see that the visual indication of focus does not rely on the browser default and does do not rely on color alone. As you use the keyboard to tab through the controls notice that along with the color change, other non-color dependent indicators are provided such as a thicker border, shadows, and font weight and style.
Enhanced Visual Indication of Focus Example:
In the previous example, you may have also noticed that using the mouse to hover over the controls provides a similar experience. We often see the CSS pseudo hover class used to enhance the mouse experience, including the CSS pseudo focus class is an easy way to tap into what has already been provided via the styles for the mouse hover.
Accessibility Includes a Visual Indication of Focus
In all cases, a visual indication of the current keyboard focus should be provided. As you tab through a page, verify that a visual indication of keyboard focus is provided in a way that is accessible and does not rely on color alone. If at any time the visual indication of keyboard focus is not displayed while tabbing through the page, you have an accessibility issue which may also be a blocking issue.
Change of Context
The last keyboard related issue we want to discuss in this post is an unexpected change of context.
Changing the current input focus can cause confusion for several groups of users (non-visual, low-vision, cognitive, keyboard-only, etc.). In some situations, the automatic change of context can also create a blocking issue for users.
In the following examples, you can experience how the automatic changing of context can impact a keyboard-only user.
Change of Context – Automatic
Below is a drop list control (or select control). It has several fruit options you can choose. Tabbing to the control and selecting an option will trigger the current keyboard focus to jump to another location, in this case the paragraph after the control.
To try this out for yourself, tab to the drop list control and then press the down arrow key until you get to the option for "fig".
Automatic Change of Context Example:
As you can experience firsthand, trying to select "fig" from the list of options can be problematic. This issue can impact a keyboard-only user, screen reader user, magnifier user, etc. It is not an accessible experience.
While it is true that if you expand the list of options by pressing ALT+DOWN (on Windows) you can navigate the entire list of fruits using the arrow keys. The input focus will still jump after making a selection, which may be OK depending on where that focus jumps, but keep in mind that when most screen readers encounter a drop list control, the screen reader instructs the user to use the arrow keys to make a selection. It doesn't say, expand the list first!
Change of Context – User Controlled
It is always best to give control to the user on when they want to invoke a change of context. This way they can expect the change will occur and not be left wondering what just occurred…especially in the case of a non-visual user.
The next example is also a drop list control with several fruit options. The difference is that now the user can select from the list and the “submit” their selection using a button. While this does require an additional keystroke or two it is a lot less likely the user will encounter problems. Try it out for yourself, tab to the control below, select “fig”, and then submit that selection.
User Controlled Change of Context Example:
Did you noticed that the user was able to accomplish the task and at the same time maintain their context within the page? Sometimes, an extra keystroke or two is required to provide a more accessible experience for all.
Accessibility Allows the User to Maintain Control of Context
When using the keyboard to TAB through the form controls, make sure interacting with a control does not automatically change the user’s context (e.g., place the keyboard input focus elsewhere, refreshes the page, etc.), unless the user has been informed clearly that this action is going to happen before it occurs. Otherwise, this is an accessibility issue can in some cases can be a blocking issue for users.
Summary
We focused on three critical areas for keyboard testing. They are:
- Interactive Elements
- Visible Indication of Focus
- Change of Context
There is a lot more involved when it comes to keyboard testing, but with this basic primer, you should be able to identify some keyboard issues that, if fixed, can boost the accessibility of your website for keyboard and assistive technology users.
Doing this type of keyboard testing on your site will also help you achieve conformance with the following WCAG 2.1 Success Criteria:
- Success Criterion 2.1.1: Keyboard – Level A
- Success Criterion 2.4.7: Focus Visible – Level AA
- Success Criterion 3.2.2: On Input – Level A
- Success Criterion 3.2.5: Change on Request – Level AAA
As a reminder, this blog series is not intended as a complete guide to creating accessible content. Instead, its purpose is to help understand and address some accessibility issues that can help create a more accessible experience for users and reduce the risk exposure of legal complaints. If you are looking for a complete guide to ensure WCAG 2.1 Level A/AA conformance, consider a subscription to WebAlign.
WebAlign
Want to See More Content Like This?
Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!
We're Here to Help When You're Ready
Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.
0 comments on “First Steps to an Accessible Website (Part 7)”