Keyboard and Focus – Accessibility Guidelines

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.

Development Considerations

• Do not remove standard keyboard accessibility behavior from native HTML interface elements (such as links, buttons, form elements).
• Add keyboard accessibility to custom developed interface elements.
  • Use the proper ARIA attributes, and javascript event handling.
• Make tooltips mouse and keyboard accessible. Review ARIA tooltip example.

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.

Failure to meet this requirement could interfere with any use of the page. Refer to Requirement 5 – Non-Interference to learn more.

Development Considerations

• This usually occurs when external content is embedded within a page. Ensure the keyboard user can exit the embedded content.

Focus Visible #

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

Development Considerations

• Do not intentionally remove the outline or other visual indicators on interactive, focusable element.
• After deactivating the element currently in focus, set the focus to a specific location. Otherwise, the focus will be lost, effectively sending the focus back to the top of the Document Object Model (DOM).

Focus Order #

If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.

Development Considerations

• Code content so elements are tabbed to in a sequential order that matches visual presentation of content (left to right, top to bottom).
• When adding an element to the keyboard tab order, use tabindex=”0”
  • tabindex=”-1”: Makes the element focusable but not part of the (DOM) Tab sequence.
  • tabindex=”0”: Makes the element focusable and includes it in the (DOM) Tab sequence.

On Focus #

When any component receives focus, it does not initiate a change of context.

Content/Design Considerations

• Automatic changes should not be initiated when a component receives focus. Provide a clearly named control, such as a button, to initiate such changes.

Development Considerations

• Examples of changes in context are:
  • Opening a new window
  • Moving focus to a different component
  • Going to a new page (or anything that would look to a user as if they had moved to a new page)
  • Significantly re-arranging the content of a page

Don’t use javascript to perform a function that changes the page’s context on the focus event (onfocus).