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.

Synposis

  1. If a link changes appearance with a hover event, make sure it also changes with a focus event. See the Rollovers page for examples.
  2. 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" attribute can be used to force a TAB stop at that tag (e.g a P).
  3. For interactions requiring a click, make sure the click works with the a keyboard input for ENTER/RETURN as well as a mouse. This is automatic for Web links and forms, but may need to be programmed if using technologies such as JavaScript or Flash.
  4. Avoid keyboard traps where a user cannot exit a function with the keyboard. For example:
    1. 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.
    2. 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.
  5. 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.
  6. 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.
  7. 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.