• Media Type Web > Keyboard Accessibility
  • State Active
  • Advisory No

All functionality must be actionable with the keyboard regardless of the input method used. This requirement is necessary to ensure operation by people without vision (who cannot use a mouse) as well as by people with dexterity impairments. Often time people with dexterity or mobility impairments use alternate keyboards or input devices that emulate the keyboard. These include such assistive technology as on-screen keyboards and speech recognition software. Additionally, many users with low vision also have trouble tracking a mouse pointer and are likely to use the keyboard. Navigation and functionality that is dependent on specific devices such as a mouse may not be available to such users. Content providers should ensure that all functionality can be used from the keyboard. This does not prohibit the providing functionality with the mouse -- in fact providing access through multiple methods is preferential. The one exception to this best practice is for functionality that specifically requires a specific path by the users pointing device rather than the result of the user actions with the pointing device.

This manually checked best practice is the general case of the more specific automated best practice Ensure the sole use of device dependent event handlers is avoided. If the more specific best practice was automatically flagged for a given element this best practice does not need to be flagged for the same element.

Compliant Example

<form>
<input type="text" name="user_name" id="user_name />
<label for="user_name">User Name</label>

<input type="password" name="password" id="password/>
<label for="password">Password</label>

<input type="submit" value="Login">
</form>

Non-Compliant Example

<form>
<input type="text" name="user_name"/>
User Name

<input type="password" name="password"/>
Password 

<span onclick="doSubmit()">Login</span>
</form>

Utilize standard HTML components to handle aspects of navigation and form submission. For example, replace non-standard elements that cause navigation with proper a (anchor) elements, and replace non-standard elements that trigger form submission with proper form input or button elements.

Many websites offer a website navigation bar with mouse-driven pull-down or rollover menus that offer links to topic pages in various site sections (e.g. About Us, Products). The ideal is for this functionality to be equally accessible from the keyboard. Short of that, the alternative is to ensure that the menu parent element that triggers the appearance of the menu to be a keyboard-focusable element (link), and that the resulting site section page offers the same set of topic links offered by the menu.

Developers should ensure that when device dependent event handlers are used, there are redundant events to allow users of assistive technologies a method to access the functionality. For instance, if a mouse event such as onMouseOver is used, onFocus must also be included. Alternatively, authors should remove the event handlers if they do not wish to add a redundant device dependent one.

Developers must also ensure that when keyboard event handlers are associated with elements that the element must be able to receive keyboard focus. For elements that do not typically receive focus such as the div or img element a tabIndex attribute of 0 or greater must be set on the element. Note, anchor tags without href attributes but with onClick attributes will not by default receive keyboard focus. The following device dependent event handlers correspond to the device independent event handlers.

Example Keyboard Alternative
Event Handler Alternative
OnClickOnKeyPress
OnMouseDownOnKeyDown
OnMouseUpOnKeyUp
OnMouseOverOnFocus
OnMouseOutOnBlur
OnDblClickOnKeyDown
ngClick (angular)ngKeypress (angular)

Note: Most browsers fire the onClick event handlers for certain elements such as the anchor when the Enter key is pressed on an active element. Adding in a redundant event handler will have the effect of firing the event twice when the keyboard is activated which may be non-optimal. For such elements, developers should not provide a redundant event handler for the onClick event. The elements are:

  • a
  • input
  • area
  • button

When the onclick handler and tabIndex attribute are used in conjunction on an element such as an img element a keyboard event handler must also be used to ensure the element is keyboard accessible. It is strongly recommended to use anchor, button, or input elements for user actions and to not use elements such as div and img for this purpose as these elements have the broadest support for assistive technologies and browsers.

Organization Standards

  • § 508-1194.22 Web Sites and Applications
    • (l) Ensure scripts are accessible
  • Section 508 and 255 (Revised 2017)
    • Chapter 3: Functional Performance Criteria
      • 302.2 With Limited Vision
      • 302.1 Without Vision
      • 302.7 With Limited Manipulation
      • 302.8 With Limited Reach and Strength
  • WCAG 2.0 Level A
    • 2.1.1 Keyboard Accessibility
  • WCAG 2.1 Level A
    • 2.1.1 Keyboard

Other Mapped Standards

  • § 508-1194.21 Software Applications and Operating Systems
    • (a) Ensure keyboard control of application
  • § 508-1194.31 Functional performance criteria
    • (a) Ensure access for blind and visually impaired
    • (b) Ensure access for low vision users
    • (f) Ensure users with mobility impairments can use application
  • 47 CFR 14. Advanced Communication Services
    • 47 CFR 14.21 Performance Objectives
      • (b) Accessible
        • (b)(1) Input, control, and mechanical functions shall be locatable, identifiable, and operable
          • (b)(1)(i) Operable without vision
          • (b)(1)(ii) Operable with low vision without relying on audio
          • (b)(1)(v) Operable with limited manual dexterity
  • BITV 2.0 (Priority I)
    • 2.1.1 Tastaturbedienbarkeit
  • EN 301 549 v3.2.1
    • Chapter 4: Functional Performance
      • 4.2 Functional Performance Statements (FPS)
        • 4.2.1 Usage without vision
        • 4.2.2 Usage with limited vision
        • 4.2.7 Usage with limited manipulation or strength
    • Chapter 9: Web
      • 9.2 Operable
        • 9.2.1 Keyboard accessible
          • 9.2.1.1 Keyboard
  • HHS HTML 508 Checklist (Pre 2019)
    • HHS Web 508 Checklist (l)
      • (12.1) Is any content or functionality provided by JavaScript through mouse action also provided through keyboard-triggered event handlers?
  • JIS X 8341-3: 2004 - Technical Standards Subpart 5
    • 5.3 (a) Ensure device independence
  • KWCAG
    • 2-4 - Ensure all functionality can be controlled from the keybard
      • 2-4-1 - Ensure keyboard control all contents
    • 3-3 - Ensure forms are accessible
      • 3-3-2 - Ensure access the information for online form or move between forms when only with keyboard
    • 4-1 - Ensure plug-ins are directly accessible
      • 4-1-1 - Ensure that the embedded content itself is accessible
  • NFB Certification
    • Device Dependency
  • Telecommunications Act Accessibility Guidelines
    • 1193.41 Input, control, and mechanical functions.
      • (a) Operable without vision. Provide at least one mode that does not require user vision.
      • (b) Operable with low vision and limited or no hearing. Provide at least one mode that permits operation by users with visual acuity between 20/70 and 20/200, without relying on audio output.
      • (e) Operable with limited manual dexterity. Provide at least one mode that does not require user fine motor control or simultaneous actions.
  • WCAG 1.0 Priority 2
    • 06.4 Ensure device independence
  • WCAG 2.0 Level AAA
    • 2.1.3 Keyboard (No Exception)
  • WCAG 2.1 Level AAA
    • 2.1.3 Keyboard (No Exception)
  • WCAG 2.2 Level A
    • 2.1.1 Keyboard
  • WCAG 2.2 Level AAA
    • 2.1.3 Keyboard (No Exception)

  • Severity

    8 (red)
    in range of 1 to 10

  • Noticeability

    4 ()
    in range of 1 to 10

  • Tractability

    8 ()
    in range of 1 to 10