Usability & Web Accessibility – Focus & Keyboard Operability

Posted by Yale University | Date Accessed: August 15, 2022

Download the Keyboard Operability Developer Brown Bag slides(link is external).

Users Who Do Not Use a Mouse

Many computer users do not use a mouse, trackpad, or other pointing device when interacting with web pages, either due to preference or to impairment. A user may not use a mouse because that user:

  • is blind;
  • has low enough vision such that they have difficulty following a mouse;
  • has a motor impairment that prevents their using a mouse; or
  • prefers to use a keyboard to complete certain tasks, such as filling out a form.

In these cases, the user likely uses a screen reader, keyboard, or emulated keyboard. User interfaces should be implemented in such a way that they can be used without a mouse.

It is important to note that keyboard operability is also a concern with mobile devices. It is common for users with disabilities to use an external keyboard with a mobile device, especially if those users find touch gestures difficult.

WebAIM provides a nice summary of the issues surrounding keyboard accessibility.(link is external)

Requirements

To meet the accessibility needs for these populations, user interfaces should meet a number of requirements:

  • All functionality should be operable through a keyboard without requiring specific timings for individual keystrokes.
  • Keyboard focus should be trapped within a component,
  • Keyboard shortcuts should be avoided. If they are implemented, they should not interfere with common screen reader and browser shortcuts, and can be turned off.
  • Keyboard focus should always be visible and easy to perceive.
  • Focus order should be meaningful and promote ease of use.
  • When a user initiates a change in focus, there should not be a change in user agent, viewport, content, or an additional change in focus.
  • Any complex interactions should conform to the best practices recommended in the ARIA 1.1 Authoring Practices(link is external) document.

Understanding Focus

When an HTML element is able to handle keyboard input, it is said to have focus. Exactly one element is able to have focus in a time. In most browsers, users can move focus by pressing the Tab key and the Shift + Tab keys.

The following elements can receive focus:

  • <a> tags with an href attribute
  • Form controls and buttons (unless the element is disabled)
  • Any element with a tabindex.

Understanding tabindex and Focus Order

For an otherwise unfocusable element to become focusable, it must have a tabindex attribute. Elements with a negative tabindex can receive focus through scripting but not through keyboard tabbing.

A web page’s focus order must preserve a page’s meaning and promote ease of use. A page’s focus order is calculated as follows:

  • First, focus proceeds through elements with a tabindex greater than 0, in ascending order. If multiple elements have the same tabindex, elements earlier in the DOM will occur before elements later in the DOM.
  • Then, focus proceeds through all remaining items according to their source order in the DOM. Elements with tabindex="0" will occur according to their place within the DOM.
  • Items with negative tabindex are removed from the focus order (but can gain focus by scripting).

In general, avoid using tabindex greater than 0. Doing so creates maintainability problems and unexpected user behavior.

Focus order should be logical, and should generally follow the visual order of the page. CSS positioning and floats do not affect the focus order, even if they do affect the visual order.

Mozilla’s accessibility documentation includes a great explanation of tabindex.(link is external)

Focus Styling

For a site to be accessible, it must be easy for keyboard-only users to perceive where focus is at all times. There must always be a visible element with focus, and that focus must be obvious.

Each browser implements a different focus style, and those focus styles are very distinct from one another. Some browsers may implement a faint blue outline or a thin dotted line. Regardless, default browser focus styles are generally not sufficient to provide an easy to use experience(link is external). To make matters worse, many CSS resets remove focus styles altogether.

Best Practice: Provide Custom Focus Styles

Developers should implement (and designers should design) focus styles for keyboard operable elements as a matter of routine. Doing so will create a consistent experience across browsers, and will do more to make an accessible experience for keyboard-only users. Custom focus styles should be highly salient, and have contrast ratios of 4.5:1 to ensure they are perceivable to colorblind users.

Developers may want to implement a generic focus style to ensure that all focusable elements are somewhat accessible. Such focus styles might include thick outlines, background glows or drop shadows, and underlines. At a minimum, Yale recommends something like the following:

*:focus {outline: 3px dashed;}

Developers and designers are encouraged to design their own focus styles, including custom focus styles for particular elements.

Another best practice is to ensure that any hover styles are also provided on focus, such as underlines, background color changes, or animations. Because hover and focus typically serve the same function, they can and should share styling rules.

Best Practice: What-Input JavaScript Library

While keyboard tabbing manipulates the location of focus, mouse clicks do, as well. On some browsers, an element, such as a form field, will receive visual focus styling when it is clicked on. Many designers and developers find this behavior undesirable, preferring focus styling to only be present only if a keyboard is used.

What-Input is a JavaScript library that listens for the kind of input a user is using(link is external) (keyboard, mouse, etc). The library can be used to set attributes in the DOM, which can in turn be the basis of CSS selectors. For example, with this library, focus styling can be hidden when using a mouse, but visible when using a keyboard.

Best Practice: Flying Focus JavaScript Library

Even with noticeable focus styles, some users may find it difficult to perceive where focus goes when tabbing through an interface. Flying Focus is a JavaScript library that creates a visible transition(link is external) so that users can see where focus travels to when tabbing.

Flying Focus is implemented on this website.

Widgets, Interactions, and Keyboard Operability

Access Keys and Keyboard Shortcuts

Avoid implementing access keyboard shortcuts unless you are designing an extremely complex web application. If keyboard shortcuts and access keys are implemented, they must not interfere with common screen reader, browser, and operating system shortcuts.

Focus and Change of Context

When a user changes focus, a web page must never:

  • submit a form
  • launch a new window or application
  • move focus to yet another element
  • update page content substantially

These kinds of changes are known as a “change of context,” and they are strictly forbidden in WCAG 2 SC 3.2.1.

Focus management

For many complex interactions and custom widgets, it may be necessary to manage focus via scripting, especially in response to an event on the page or user input. For example, when a modal is launched, focus must manually be moved to within the modal. And when the modal is dismissed, focus should be moved to the trigger that launched the modal (if applicable), or another appropriate place.

For complex widgets with many potential focusable elements, it may be preferable to use the Tab key to move focus into and outside the widget, and use arrow keys and scripting to manipulate focus within the element. This concept is known as roving tabindex. Developers implementing complex widgets that make use of arrow keys should consult the ARIA 1.1 Authoring Practices document’s section on keyboard navigation inside components(link is external).

Widget and Interaction Design Patterns

When designing a widget or interaction, consult the ARIA 1.1 Authoring Practices document(link is external). One purpose of the document is to provide model implementations and best practices for dozens of interactions. The design patterns include specifications for managing focus and which keystrokes should be made implemented to manipulate the widgets. (The Authoring Practices document also provide guidance for screen reader accessibility for each widget.)

Other JavaScript Concerns

Developers should know the difference between device-dependent and device-independent events, and should choose wisely which events to use. Interactions that are triggered on onMouseOver or onMouseDown are likely not operable to keyboard-only users, as those are device-specific. Device-independent events, like onFocus, onBlur, and onClick, can be fired by the mouse and by the keyboard. (For natively focusable elements like buttons and anchors, a keyboard Enter keystroke will fire a click event. On elements made focusable by adding tabindex, on the other hand, an Enter keystroke may not fire a click event, and a developer may have to include an onKeyPress event handler.) WebAIM provides a long discussion on accessible JavaScript events(link is external).

Particular care should be used when a page is dynamically updated with AJAX, as the element that contains focus may be destroyed while it has focus. This is never acceptable, as there must always be an existing element with visible focus at all times.

For single page apps, place focus on the <h1> of each new page after it has been rendered.

Validating Keyboard Accessibility

Validating keyboard accessibility is an important step in evaluating accessible interactions generally. To validate keyboard accessibility, complete the following checklist on a variety of devices, including mobile devices with external keyboards:

  • Disable your mouse, and use just a keyboard.
  • Ensure that the focus order is intuitive and follows the visual order of the page.
  • Ensure that all functionality is available and easy to use via the keyboard alone.
  • Ensure that the focus is never trapped in an element and cannot be escaped by the keyboard alone.
  • Ensure that focus is visible at all times, on all browsers, in a way that is obvious to people with colorblindness or low vision.
  • Ensure that there is no change of context whenever a user changes focus.
  • Ensure that interactions follow the ARIA 1.1 Authoring Practices.
About This Article:

A Life Worth Living has copied the content of this article under fair use in order to preserve as a post in our resource library for preservation in accessible format.  Explicit permission pending.

Link to Original Article: https://usability.yale.edu/web-accessibility/articles/focus-keyboard-operability