Providing good access to all the controls and functions of the software via the keyboard as well as the mouse benefits many users, not just those using access technologies. It also helps people using laptops, computers with broken or missing mice, or people who just work better with the keyboard than the mouse.
"All input functionality needs to be keyboard operable but not necessarily all user interface elements. If there are multiple ways to perform a task, only one of them needs to be available from the keyboard, though it is best if all possible forms are keyboard operable."
ISO/FDIS 9241-171:2007, 9.3.2 Enable full use via keyboard, Note 5.
Large number of controls
We often come across screens that contain a huge number of controls. There are sometimes good reasons for this but less cluttered screens are often more usable.
By convention, the Tab key is used to move from one control to the next. If the 'OK' button can only be reached with 25 tab presses then it makes sense to address effective keyboard navigation. Solutions that we have seen include:
-
Simplified linked screens with fewer controls on each one;
-
Accelerator keys to move between functional areas of the screen (such as Control + Page Up or Control + Page Down);
-
Consistent hotkeys to reach frequently used controls (such as Alt + O for every OK button).
Tables
Effective keyboard access is often an issue in tables, where it is important for the keyboard user to be able to reach all data in the table. Even a table with just four rows and four columns would demand sixteen tabs to get through the contents one cell at a time.
Coding so that the down arrow will move by rows and the tab moves by columns improves efficiency but there will still need to be a way for a keyboard user to move past a table without having to cursor through every cell, while still allowing keyboard access to the contents. Splitting the screen into functional areas and providing a keystroke to move from one area to the next may work for you.
Tab order
From the examples above, it is clear that the tab order is a critical aspect of accessibility for a keyboard user. The convention is "top to bottom, left to right," but there can always be exceptions where this makes sense in context.
For example, if a postcode is used to look up an address, it would be logical for the postcode field to be before the address in the tab order, even if it is not displayed that way on the screen.
Requiring data to be entered in a field before the cursor can move on is to be avoided. Users who are blind tend to explore a dialog by tabbing around from the keyboard. Trapping the cursor prevents a user who cannot see the fields in a dialog box from finding out what it contains.
Read only information
This is an issue that mainly affects blind users who operate from the keyboard. The most effective way to access information on the screen is to move the keyboard focus to the information. This option is not conventionally available for read-only data, such as a print preview or a table of results.
It is possible to use the advanced features of a screen reader to read this type of information but this is not very easy to do. The best solution is that it should be possible to move the keyboard focus to non-editable interface elements.