Keyboard Navigation Functionality Testing Explained

Web Content Accessibility Guideline (WCAG) 2.1

Guideline 2.1 of the WCAG 2.1 is one of the most important accessibility guidelines. It’s also one of the hardest to put into practice because it involves technical skill beyond aesthetic choices. It says that all functions of a given piece of web content must be made available to a user who uses a keyboard alone. Keyboard navigation functionality is essential to accessibility, it needs to be standardized and widely understood, and we think we know how to do that. Though keyboard navigability is typically considered one of those areas that requires manual testing, we’ve figured out how to automate it, which can allow developers and companies to be confident in their product’s accessibility on a level they wouldn’t have been able to attain without manual testing in the past. In this post, we’ll walk you through why keyboard navigation functionality is important, how to test for it, and our proposed solution to help standardize it.

 

Why is Keyboard Functionality So Important?

To put it succinctly, assistive technology (screen readers, mobile interfaces that translate gestures into keyboard gestures, and many more) interacts with a computer through keyboards. To elaborate, The WCAG 2.1 has six success criteria on levels A and AA about keyboard interaction. Keyboard navigation is the primary way that most people using assistive technology, which includes people with visual impairments, certain mobility impairments, and more, access web content. Approximately 2.3% of Americans have a visual impairment, an estimated 2.6% have a self-care disability (i.e., they have difficulty dressing or bathing themselves), and an estimated 12.7% of all non-institutionalized Americans have some kind of disability[i]. Roughly 7% of working-age adults are likely to us a keyboard instead of a mouse, either due to necessity or preference[ii], not to mention those who use technology based on keyboard controls. Based on these numbers, we know that keyboard navigation functionality is essential to millions of people in the US alone.

The reason we’re emphasizing the keyboard is that it’s the way that virtually all people who rely on assistive technology access web content. That means, logically, that anyone who isn’t a normative user (to the extent that impacts their ability to use web services, that is) is reliant on keyboard navigation’s functionality[iii]. If you’re going to focus on one only area of digital accessibility, this is it.

Having ensured that keyboard navigation functions correctly, you can feel confident that up to 70% of WCAG 2.1 guidelines have been met[iv]. For comparison’s sake, automated testing tools that don’t include keyboard navigation functionality testing only check for about 30%[v] of WCAG guidelines (SenseIT is currently unique in that it does check for keyboard navigability). A manual accessibility test can, in theory, guarantee up to 100% of the guidelines (though even if that were the case, we don’t believe there is such thing as a 100% accessible product), but only if the person doing the test is fortunate enough to have all the necessary knowledge and make no mistakes; there’s very little standardization in manual testing.

 

How is Keyboard Functionality Testing Usually Done?

Keyboard navigation is done using the tab key and the shift+tab keys to move what’s called a focus forward and backward respectively. Links and many buttons are activated by pressing the enter key, other buttons and checkboxes are activated with the space bar, drop-down menus utilize the arrow keys, and the escape key is used to close things (like pop-up windows). The focus should be clearly, visibly defined, and you should be able to follow it with relative ease over the content of the web page you’re on.

SenseIT being the exception, keyboard navigability is tested as part of a manual test, which means that a tester receives a set of tasks to perform on a web page using only the keyboard. These tasks can be objective-based user flows or linear page-by-page navigating through the website. The tester checks to see whether they can perform the tasks they’re given, and if they can, the website “passes” the test. If they can’t perform those tasks, or the test result is convoluted (due to the focus’ color being insufficiently contrasted against its surroundings or has some other issue that obscures, but doesn’t entirely prevent a good user experience, for instance), the tester will, ideally, leave notes for improvement. There is inbuilt subjectivity, and different testers will prioritize different things, though hopefully these differences will stay within a reasonable margin.

 

How Do We Test for Keyboard Functionality?

On SenseIT’s platform, we check for keyboard functionality the same way you’re already testing for mouse-based functionality. You import your existing functionality test scripts, we transform them into keyboard navigation tests, and then we run user-flow tests on your website using our software, which mimics a keyboard-only user. That means that your keyboard navigability will be as good as your mouse-based functionality, provided that you act on the results of the test. Why this is better than manual keyboard navigation testing is three-fold: it saves time to run a test once and find all the flaws, as opposed to running it many times, correcting in between runs; it’s cheaper than paying someone an hourly rate to come perform the test many times over; and it’s not subject to human error or idiosyncrasies.

 

Turning Guidelines into Standards

We’re big fans of automated testing and continuous integration (CI) in software testing, but we recognize that there are still elements of accessibility testing that can’t currently be done without manual testing – we’re trying to close that gap, and keyboard navigation is where we’ve begun. The more we learn to automate effectively, the easier it will be for enterprises to maintain their products’ accessibility.

 

 

 

[i] Source: https://www.disabilitystatistics.org/reports/acs.cfm?statistic=1

[ii] Source: https://www.powermapper.com/blog/website-accessibility-disability-statistics/

[iii] A great read about that: https://uxdesign.cc/taking-the-keyboard-navigation-red-pill-dbb76dd73b1e

[iv] This figure is based on our internal research. If you’d like to know more, drop us a line.

[v] Source: https://www.levelaccess.com/automated-testing-tool-limitations/