Chapter 18: Use of keyboard

People with motor difficulties will have tough time in using the content if the actions are mouse dependent. The motor difficulties can range any wher between not having hands, to not having few or more fingers, to stress on  musels. Trimmers in the hands can also cause difficulty in pointing the mouse on to a particular element on the screen.

Providing keyboard access to all the functionalities of the page can solve this problem. The functionalities on the page include simple interactions such as activating a button, filling up a form to more complex interactions such as sorting a column in a table, drag and drop. Taking care that all the functionalities of the page usable by keyboard alone is required as per WCAG standards. This will also benefit low vision and blind users.

Validation for  use of keyboard

1. Open the page on a browser.
2. Navigate to all the interactive elements using the tab key of the keyboard.
3. Check if all the functionalities are navigable and actionable  by keyboard alone.
4. If a keyboard can access all the functions of the page this success criteria is considered pass, else failed.

Note: The tab key navigates users one step forward and shift + tab moves one step back. Space and enter keys are used to activate or select an element. Refer to ARIA authoring practices for complex interactions such as tabs, mega menu, accordiance

Validation for key board with screen readers

1. Open the page on the browser when screen reader is switched on.
3. Navigate all the elements of the screen with tab and shift + tab keys.
4. Listen if the screen reader is announcing the elements and keyboard is reaching the elements appropriately.
5. Check if all the funtions are usable by key board even when screen reader is switched on.
6. Repeat the navigation with up and down arrow keys. The screen reader should navigate to all the elements of the screen including non interactive elements such as headings, paragraphs, images
7. If the user is able to navigate and activate / select the elements on the screen, the success criteria is considered as pass, else it is a faiure.

Note: The same tab, shift + tab, space, enter, up and down arrow keys should work with screen reader on, For more screen reader shortcuts look at our screen reader commands page.

To pass this success criteria, both check 1 and check 2 has to be passed.

No keyboard trap

Except for the scenarios where keyboard trap is necessary for the function of the page, it should be trapped within the sections of the page. Eg: Keyboard trap is a required scenario for modal windows. In other situations such as an iFrame or similar sections keyboard shouldn’t be trapped. If keyboard trap could not be avoided and a specific key command/ access key is required to exit the trap, inform the behavior to the user before they encounters it. Also inform the commands or gestures  assigned to move away from such section in advance.

Validation for keyboard trap

1. Open the page on the browser.
2. Navigate the entire page using tab and shift + tab key of the key board.
3. Observe if the navigation of the page is effected due to a trap of keyboard in certain portions of the screen.
4. If the keyboard navigation is trapped in any sections of the page, it is an accessibility violation. Else this success criteria is passed.

Note: Repeat the same check again when the screen reader is switched on.

To mark the completion of this test validation has to be done with keyboard and also using screen reader & keyboard.

WCAG success criteria

• 2.1.1 Keyboard only (Level A)
• 2.1.2 No keyboard trap. (Level A)