Focus

Focusable Elements

If an element is interactive - i.e. if a mouse user can interact with it by hovering over it or clicking on it - those same interactions should be available using the keyboard alone.

Each interactive element must first be able to receive keyboard focus. This means that using the TAB key, a user can land on the element (the element is in “in the tab order”).

Tip

Get in the habit of “tabbing” through web pages and applications (your own as well as other sites). You’ll quickly see why tab order and visible focus are important.


Only one element can have keyboard focus at a time in a given window.

Once the element has keyboard focus, a keyboard user should be able to interact with the element using one of a few standard keyboard interactions. (Read more about these standard keyboard interactions on WebAIM’s article on Keyboard Accessibility.)

Natively focusable elements

The following elements are focusable, and in the tab order, by default:

  • <a>

  • <button>

  • Form inputs, including

    • <input>

    • <textarea>

    • <select>

  • <audio controls> and <video controls> elements (only consistently receive focus across browsers when the controls attribute is present)


The following elements are focusable and in the tab order in some browsers, but not all:

  • <iframe>

  • <embed> (depending on attributes)

  • <svg> (particularly in IE)

  • <summary> elements that are the first <summary> child of a <details> element


(For more detailed cross-browser information about focusable and tabbable elements, see Focusable Elements - Browser Compatibility Table from a11y.js.)

Tab Order

A keyboard user will often navigate a document by pressing the TAB key to move sequentially from one interactive element to the next. The “tab order” is the order in which these elements receive focus.

Generally, content should be structured in the DOM in the same order that users should encounter it, so the tab order flows naturally from left to right and top to bottom.

Tabindex

The tabindex attribute indicates whether an element is in the tab order or is not in the tab order. Avoid using the tabindex attribute to set an element’s position within the tab order.

Note: Wherever possible, use natively focusable html elements, rather than setting tabindex on an element that does not natively receive focus.

tabindex=”0”

tabindex of 0 means that an element is in the tab order. The element will receive focus based on its location in the DOM.

For elements that do not natively receive focus (e.g. a <div>), adding tabindex="0" will allow them to receive focus.

An example of when setting tabindex="0" would be appropriate: when coding custom interactive widgets, setting tabindex="0" will ensure keyboard users can navigate to the element. (Note that for custom interactive widgets, further keyboard interactions may need to be coded to make a widget keyboard accessible. See the WAI-ARIA Authoring Practices for more information on recommended ARIA usage patterns and expected keyboard interactions.)

tabindex=”-1”

tabindex of -1 means that an element is not in the tab order, but the element can receive keyboard focus programmatically. Keyboard focus will not land on the element when a user is tabbing through the page, but focus can be set to the element via JavaScript.

An example of when setting tabindex="-1" would be appropriate: to set focus to a list of errors on a user’s form submission. Drawing the user’s attention to the list of errors is important to let the user understand that something has gone wrong, and to help them fix the problem. Setting their focus to the list of errors above the form allows the user to read the list, and then to move forward in the tab order to address the errors.

Note

Set focus programmatically with caution. Be sure setting focus does not interfere with a user’s intended interaction with the content and does not happen without warning.


Avoid: tabindex=”[1 or greater]”

Setting a tabindex of greater than 0 will explicitly set the element’s position within the tab order. This will move the element out of the natural tab order of the document. Avoid setting tabindex higher than 0 as this can lead keyboard and screen reader users to miss important content, and can disorient users.

Visible Focus Styles

Keyboard focus must be indicated visually, so a keyboard user understands where they are on the page or screen. This visual focus indicator must be highly visible, and provide adequate colour contrast (see Contrast of focus styles, below).

Test visible focus styles by pressing the TAB key to move from one interactive element to the next on any webpage. Can you see where your keyboard focus is?

Default browser focus styles

Each browser applies a focus style to interactive elements by default. This style is generally applied using the CSS outline property. The style is different in each browser. Depending on the style of the element, these default styles may not be visible enough.

  • Chrome
    Chrome uses a blue glow to indicate focus for text links, buttons, and form inputs:

  • Firefox uses a black dotted outline to indicate focus for text links and buttons, and a blue outline for form inputs: 

  • IE uses a white-and-gray dotted outline for text links and buttons, and a black outline for form inputs:

  • Safari uses a light blue outline for text links, buttons, and form inputs:

Do not override the default focus style (e.g. with outline: none) without designing a new focus style that is equally or more visible than the default.

:focus pseudo-class

The :focus pseudo-class represents an element that currently has keyboard focus. This pseudo-class should be used to style the element to visually indicate its focus state.

Note: the :hover pseudo-class is often considered in a design when the :focus pseudo-class is forgotten. As long as the style provided for the :hover pseudo-class is accessible (i.e. highly visible, providing adequate colour contrast), it can also be applied to the :focus pseudo-class, to avoid having to create two styles, e.g.:


:hover,
:focus {
	[hover and focus styles here]
}


Consider accessibility and focus styles when designing hover styles, to make development easier and more accessible from the start.

Contrast of focus styles

Focus styles must provide adequate contrast both against the background of the focusable element, and against the default state of the element.

The contrast ratio between the default state and the focus state must be at least 3:1.

Chrome’s default focus style of a blue glow outline is not sufficiently visible for buttons with a light blue background. In the following screenshot, the button on the left is the default button style, and, on the right, the button has focus. It is very difficult to see the blue glow focus indicator surrounding the button on the right.


A better option might be to customize the focus style for these buttons, by changing the background color on focus. In the following screenshot, the button on the right has focus, and has been styled with a darker blue background and white text. The contrast of the darker blue background compared with the light blue background is 4.15:1. This means that users with colourblindness, and some users with low vision, will be able to perceive the change from default to focus state.

Note that when the background colour changes, the text still needs to be readable. A minimum contrast ratio of 4.5:1 between text and background colour is required. In this example the text colour is changed as well as the background colour, to ensure that the text-to-background contrast ratio is 4.5:1 or higher.

All focusable elements require a visible focus style, and depending on your site’s styles, each may require its own custom focus indicator.

Related WCAG Success Criteria