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

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:
​

​

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.

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.

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.

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.
​

​