A major blocker preventing access for screen reader users and many people with mobility issues in their hands are functions that can only be accessed with a mouse and have no keyboard alternatives.
Programming keyboard accessibility often requires some planning during the interface design phase, but can be accomplished by remembering these principles.
- If a link changes appearance with a hover event, make sure it also changes with a focus event. See the Rollovers page for examples.
- Keyboard users can tab to links and form controls by default. If they need to be able to tab to other locations (e.g. instructions in a form), the TABINDEX="0"
- Avoid keyboard traps where a user cannot exit a function with the keyboard. For example:
- If an event opens a window, make sure there is a way to use the keyboard to close the window and return the cursor to where the trigger link or button is located.
- If dropdown menu is used, make sure the keyboard user can navigate the entire menu and also exit it to a point after the menu.
- If drag and drop or sliders are used, make sure there is a keyboard alternative programmed. It could be a textbox where values can be directly entered or a series of links performing similar functions as the drag & drop/slider.
- If a calendar picker is used, it is recommended that the interface allow a user to enter dates in directly and not be required to use the calendar.
- For complex applications, keyboard alternatives (vs. using a menu) are recommended for different functions, but the list should also be easily discoverable by any user.