Keyboard Accessibility


When content can be operated through a keyboard or alternate keyboard, it is operable by people with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as by people who must use alternate keyboards or input devices that act as keyboard emulators. Keyboard emulators include speech input software, sip and puff software, on-screen keyboards, scanning software and a variety of assistive technologies and alternate keyboards. Individuals with low vision also may have trouble tracking a pointer and find use of software much easier (or only possible) if they can control it from the keyboard. 


  • Ensure that users are not trapped in the content.  Users should be able to navigate out of a component using only the keyboard.
  • Use keyboard-controllable event handlers for all functionality. In addition to onMouseOver and onMouseOut, use onFocus and onBlur. Both onFocus and onBlur are device independent, meaning that they can be performed with the mouse, keyboard, or other assistive technology.
  • Use the onClick event handler only on a link or form control which can be triggered via the <Enter> key. Don’t use onClick for plain text, table cells or <div> elements.
  • Drop down menus should not use the onChange event handler as a keyboard only user will execute an onChange event for every move down the list. Instead allow the user to select the item from a list then select a button such as GO to activate the script.
  • Make sure form inputs are available via keyboard.
  • Default keyboard navigation order must be logical and intuitive.  Structure your page’s underlying source code so the reading order is correct, using CSS to control visual presentation.
  • Make sure the tab order of forms from field to field is correct. Don’t use tabindex to change the tab order. The tab key is used for many elements on the page and changing the tab order may make some of these inaccessible.
  • Don’t use Access Keys to provide keyboard accessibility. Screen readers already have lots of key combinations defined. If you create a special access key, you are likely to overwrite a key combination that is already used by the screen reader.
  • HTML 5 <audio> and <video> elements allow browsers to provide the controls for the player.  In Firefox and Opera the media controls are accessible using the keyboard.

WCAG 2.0 Guideline

Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard

2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints.

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

Suggested Tools for Checking Keyboard Functionality

Try accessing all elements on a page using the keyboard only. 

Where can I find more information on Keyboard accessibility?