Accessible design has become increasingly important to our global customers especially for those customers who come from countries where laws regulate the level of Accessibility required to meet basic conformance. One basic requirement is that websites or applications are fully accessible by keyboard navigation. Accessibility is not limited to keyboard input alone but encompasses all other input methods – mouse, voice, etc. For first-time Accessibility testers, keyboard navigation is the easiest place from which to start their testing journey
Mechanics of Keyboard Navigation Accessibility testing on Windows 10 and Mac devices
After launching the testing environment, you may check which in-scope test elements are accessible by using your desktop keyboard. Once the test environment fully loads, you may press the TAB key to confirm that each of the following items receives input focus - all menu items, links, buttons, input fields, checkboxes, etc. Check that you may activate selections by pressing ENTER/RETURN key. Confirm that drop-down controls expand when you give them input focus via TAB selection and press the SPACE bar. Please ensure that there are no “keyboard traps” (a keyboard trap occurs when the user TABs onto an element and cannot go forward or in the worst case is unable to move from the TAB’ed element in either direction) and that all action items are accessible using TAB key. Also, it important to confirm you are able to reverse course thru the various controls by using the keyboard combo SHIFT+TAB to traverse one or more steps backward.
The keys mentioned above are not the only ones you can use while testing the Keyboard Navigation. You can find a detailed list of keyboard keys below:
Key or Key Combination
Navigates through the active elements
This navigation progress is indicated by a change of highlighted focus
Reverse navigation through the active elements
Used to activate selected element
Drop-down menus, Toggle controls, etc.
Used for navigation within control
Traverse menus, travel left/right/up/down thru text fields, etc.
Used to exit an element
Closes a menu list, collapse a drop-down menu, etc.
Used to navigate to the top of the page
Mac equivalent fn + LEFT ARROW
Used to navigate to the end of the page
Mac equivalent fn + RIGHT ARROW
Used to increase a slider value by 10%
Mac equivalent fn + UP ARROW
Used to decrease a slider value by 10%
Mac equivalent fn + DOWN ARROW
Note: Remember that when reporting Keyboard Navigation Accessibility bugs, you are not allowed to record the sound in the screencast.
Note for Windows 10 users: Use the Windows On-Screen Keyboard app to reproduce the bug in the screencast. To quickly open the On-Screen Keyboard on your Windows 10 device simultaneously press Win+CTRL+O keys on your physical keyboard.
Note for Mac users: To open the Keyboard app on Mac, simultaneously press Option+Command+F5, select Accessibility Keyboard and click on the Done button.
WCAG 2.1. checkpoints
Before we focus on the success criteria related to the Keyboard Navigation, we need to remind you that our platform runs tests for A and AA levels of Accessibility conformance. Level AAA of Accessibility conformance is not in the scope of Test IO Accessibility testing.
There are 4 success criteria related to the Keyboard Navigation that should be met to ensure that the customer’s environment is accessible for all users: 2.1.1., 2.1.2., 2.1.3, and 2.1.4. As 2.1.3. belongs to the AAA level of conformance, we will not include it in our analysis.
2.1.1. Accessibility checkpoint
This success criterion is intended ensure that all elements are within the reach of users who use the keyboard and other input options to access the web content. Users who benefit from Keyboard Navigation Accessible web content are mostly visually impaired, or have physical disabilities that prevent them to using a mouse precisely (e.g. hand tremors).
To test if the environment fails for these criteria, use the keys mentioned above to focus and activate selections. If an element in the scope of the test is not reachable using the keyboard, you should submit a bug. Remember that 2.1.1. issue is a Level A Accessibility bug and that Level A bugs are very important to our customers.
2.1.2. Accessibility checkpoint
This success criterion is intended to make sure that the user doesn't get trapped while "tabbing" through the web content. To test the environment for this criterion, use TAB at your keyboard to make sure that you can reach any action feature and that you don't get locked on one element while "tabbing". As with the previous checkpoint, 2.1.2. is also a Level A Accessibility bug.
2.1.4. Accessibility checkpoint
This success criterion is intended to make sure that if the single character key shortcuts are active within the environment, that they are active only when they have focus, or that there is a mechanism to turn them off or to remap the shortcuts to include more than one key. Regarding the severity, 2.1.4. is the Level A severity Accessibility bug.
Note: Here you need to bear in mind that as in any test on our platform, you need to be careful not to submit a duplicated bug.