Keyboard Accessible 2.1

Understanding Guideline 2.1 opens in new window

Acceptance Criteria (must meet 1)
  1. Turn off: A mechanism is available to turn the shortcut off;
  2. Remap: A mechanism is available to remap the shortcut to use one or more non-printable keyboard characters (e.g. Ctrl, Alt, etc);
  3. Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.
Notes

If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters.

Examples

  • Drag and drop feature must also support cut and paste or have form controls to move objects.
  • Ensure the functionality provided by mousing over an element is available through the keyboard using the focus event.
  • Ensure the functionality provided by mousing up on an element is available through the keyboard using the keyup event.
  • Ensure the functionality provided by mousing out of an element is available through the keyboard using the blur event.
  • Ensure the functionality provided by mousing down on an element is available through the keyboard using the keydown event.
Functions
  • The use of physical controls such as links, menus, buttons, checkboxes, radio buttons and form fields.
  • The use of features like drag and drop, selecting text, resizing regions or bringing up context menus.
  • Adding or removing an item from a shopping cart.
  • Initiating a chat session with a sales representative.
Acceptance Criteria
  1. Identify all functionality on the content.
  2. Check that all functionality can be accessed using only the keyboard or keyboard interface.
a, button, or input Acceptance Criteria
  1. In a user agent that supports Scripting:
    • Click on the control with the mouse.
    • Check that the scripting action executes properly.
    • If the control is an anchor element, check that the URI in the href attribute of the anchor element is not invoked.
    • Check that it is possible to navigate to and give focus to the control via the keyboard.
    • Set keyboard focus to the control.
    • Check that pressing ENTER invokes the scripting action.
    • If the control is an anchor element, check that the URI in the href attribute of the anchor element is not invoked.
  2. In a user agent that does not support Scripting:
    • Click on the control with the mouse.
    • If the control is an anchor element, check that the URI in the href attribute of the anchor element is invoked.
    • Check that it is possible to navigate to and give focus to the control via the keyboard.
    • Set keyboard focus to the control.
    • If the control is an anchor element, check that pressing ENTER invokes the URI of the anchor element's href attribute.
Notes

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.

To implement this technique, first determine what functionality is available to users on the page. In this step, it is important to consider functions performed using both the mouse and the keyboard together.

Making Actions Keyboard Accessible by Using the Onclick Event of Anchors & Buttons

Examples: https://www.w3.org/TR/WCAG20-TECHS/SCR35.html opens in new window

Although click is in principle a mouse event handler, most HTML and XHTML user agents also process this event when a native HTML control (e.g. a button or a link) is activated, regardless of whether it was activated with the mouse or the keyboard. In practice, therefore, it is not necessary to duplicate this event when adding handlers to natively focusable HTML elements.

It is necessary when adding handlers to other events.
Since the keypress event handler reacts to any key, the event handler function should check first to ensure the Enter key was pressed before proceeding to handle the event. Otherwise, the event handler will run each time the user presses any key, even the tab key to leave the control, and this is usually not desirable.

Some mouse-specific functions (such as dblclick and mousemove) do not have a corresponding keyboard-specific function. This means that some functions may need to be implemented differently for each device (for example, including a series of buttons to execute, via keyboard, the equivalent mouse-specific functions implemented).

Examples

Widget Controls
  • Widget controls (like on a calendar) should be part of the tab order of the page.
  • User should be able to tab through these links and to links that follow.
Modal Dialog Box
  • Modal dialog box with two buttons (cancel or submit).
  • When dialog is open, user should only be allowed to focus on cancel or submit.
  • When focused on the last button, tabbing should take the user to the first button.
  • The dialog should only be closed if the user selects one of the two buttons.
Acceptance Criteria
  1. Tab through content from start to finish.
  2. Check to see that keyboard focus is not trapped in any of the content.
  3. If keyboard focus appears to be trapped in any of the content, check that help information is available explaining how to exit the content and can be accessed via the keyboard.
Notes

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.

To Top of page