Skip to main content

WCAG 2.1.1 Keyboard

W3C requires authors to make every content function operable through a keyboard interface, except functions whose outcomes depend on the path of a user's movement. OpenKeyNav can add an alternate keyboard path to detected click targets and configured movement endpoints. Teams must still evaluate every function across each complete page and process.

Read W3C's Understanding Success Criterion 2.1.1: Keyboard.

How OpenKeyNav helps​

OpenKeyNav gives developers several ways to add keyboard operation:

  • Click Mode labels detected targets. A user types the visible label to activate a target.
  • Move Mode labels configured source elements and destinations. A user selects both endpoints with the keyboard.
  • Heading and scroll-region commands move focus among detected headings and scrollable regions.
  • Debug labels flag some pointer-clickable elements that OpenKeyNav's heuristics consider unfocusable. Developers can investigate those elements during development.

Users can reach distant targets with fewer keystrokes and operate configured pointer-driven interactions by selecting their endpoints.

Implementation guidance​

Preserve conventional keyboard operation​

Developers should start with native HTML controls and established widget patterns. Buttons should respond to Enter and Space. Links should use valid href values. Composite widgets should follow their established arrow-key, Home, End, and Escape patterns.

Developers should preserve Tab, arrow-key, Enter, Space, and Escape behavior when they add OpenKeyNav as another route. Accessibility best practices covers semantics and focus management.

Configure every movement workflow​

Developers must identify each source and destination for Move Mode. The callback must complete the same outcome that pointer users receive.

const openKeyNav = new OpenKeyNav();

openKeyNav.init({
  modesConfig: {
    move: {
      config: [
        {
          fromElements: '.moveable-item',
          toElements: '.drop-zone',
          callback: (item, destination) => {
            destination.appendChild(item);
          },
        },
      ],
    },
  },
});

The host application should announce selection, cancellation, errors, and completion. It should also place focus where users can continue the task. Drag-and-drop Mode covers source and destination configuration.

Make the alternate path discoverable​

Developers should provide visible instructions or a visible control for enabling OpenKeyNav. Instructions should name the activation command and explain how users can exit a mode. Quick Start Guide covers the default commands.

Limits​

Teams establish conformance with 2.1.1 by evaluating every function across complete pages and processes. OpenKeyNav covers a narrower set of interactions.

  • OpenKeyNav can operate only the targets that it detects or developers configure.
  • The host application supplies accessible names, roles, values, and states. Generated visual labels serve a different purpose.
  • Developers correct illogical focus order and missing focus indicators in the host application.
  • Debug labels use heuristics and can produce false positives and false negatives.
  • The host application must preserve every state and outcome available through pointer input.
  • Teams must test path-dependent interactions separately. W3C excludes only functions whose outcomes require the movement path itself, such as freehand drawing.

Accessibility and WCAG Support covers related criteria and whole-page conformance.

Verification checklist​

Test each supported browser and assistive technology combination with OpenKeyNav off and on.

  1. Complete every task without a mouse or touch input.
  2. Confirm that each pointer outcome has a keyboard route.
  3. Confirm that OpenKeyNav exposes every intended click target, source, and destination.
  4. Confirm that users can enter and exit each mode without a timed keystroke sequence.
  5. Confirm that focus stays visible and moves to a useful location after each action.
  6. Confirm that the application communicates selection, errors, cancellation, and completion programmatically.
  7. Confirm that standard control and widget commands still work.
  8. Repeat dynamic workflows after content updates, route changes, validation errors, and asynchronous loading.