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

All functionality must be actionable regardless of the input method used. This requirement is necessary to ensure that people who are blind, people with low vision, and people with dexterity impairments who do not use the mouse can access all functionality. Often, people with these disabilities use alternate keyboards or input devices that emulate the keyboard to the exclusion of the mouse. These alternate input devices may include assistive technologies such as on-screen keyboards and speech recognition software. Navigation and functionality that is dependent on specific devices such as a mouse therefore is not available to all users. Content providers should ensure that all functionality can be used from the keyboard. This does not prohibit developers from 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 requires a specific path by the users pointing device, rather than the result of user actions with the pointing device.

This automatic best practice is the specific case of the more general manual best practice Ensure JavaScript functionality is accessible from the keyboard. If this more specific best practice was automatically flagged for a given element the more general best practice does not need to be flagged for the same element.

Elements that utilize device-dependent event handlers as the sole means of providing dynamic functionality should be avoided. An event handler is a software function that responds to a user input event, such as a mouse click or key press. Event handlers that rely solely on mouse-related events, such as onMouseOver, cannot be triggered by users that do not use a mouse. Device independent event handlers where supported by the assistive technology can also be used to meet this best practice.

Compliant Example

<a href="http://www.yahoo.com" onMouseOver="window.status='Go to the
yahoo homepage':return true" onFocus="window.status='Go to the yahoo
homepage':return true">
Yahoo Home Page
</a>

Non-Compliant Example

<a href="http://www.yahoo.com" onmouseover="window.status='Go to the
yahoo homepage':return true">
Click here
</a>

Developers should insert a redundant device-dependent event handler to allow users of assistive technologies a method to access the functionality. Alternatively, authors should remove the event handlers if they do not wish to add a redundant device-dependent one. Event handlers that depend on a device, generally the mouse, should contain redundant non-device-dependent event handlers.

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
ng-click (angular)Any key event

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 (with a working href attribute)
  • 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.

Standard Specific Recommended Changes

Mobile Web 1.0 > 5.1 Overall Behavior
Many mobile devices are touch based and as a result lack support for mouse device specific events such as onmouseover. These device specific events should be avoided or alternatives provided to ensure full functionality.

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
  • Baseline Tests for Software & Web Accessibility (v2.0.2 2017)
    • 1. Keyboard navigation
  • DHS - Section 508 Compliance Test Process for Application (v 4.0)
    • 1.1 Keyboard Access
      • 1.1 A. An interactive element or function cannot be accessed or activated by keyboard
  • 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 (2019)
    • Section C: Keyboard Navigation
      • C1 Are all elements that can be operated by a mouse also able to be operated by keyboard?
  • HHS HTML 508 Checklist (Pre 2019)
    • HHS Web 508 Checklist (d)
      • (4.6) With CSS disabled, is any content or functionality provided by the CSS through mouse action also provided through keyboard-triggered event handlers?
    • 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
  • Mobile Web 1.0
    • 5.1 Overall Behavior
      • 5.1.3 Work around Deficient Implementations
  • 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
    • 09.3 Specify logical event handlers rather than device-dependent event handlers.
  • WCAG 2.0 Level A & AA Baseline
    • 1 Keyboard Access
  • WCAG 2.0 Level AAA
    • 2.1.3 Keyboard (No Exception)
  • WCAG 2.1 Level A & AA Baseline
    • 1. Keyboard Access
  • WCAG 2.1 Level AAA
    • 2.1.3 Keyboard (No Exception)
  • WCAG 2.2 Level A
    • 2.1.1 Keyboard
  • WCAG 2.2 Level A & AA Baseline
    • 1. Keyboard Access
  • WCAG 2.2 Level AAA
    • 2.1.3 Keyboard (No Exception)

  • Severity

    8 (red)
    in range of 1 to 10

  • Noticeability

    7 ()
    in range of 1 to 10

  • Tractability

    2 ()
    in range of 1 to 10