Skip to main content

Focus on the Keyboard

The Keyboard as an Assistive Technology

When we think of assistive technology, there are a few pieces of software and settings that immediately come to mind. Screen readers, screen magnification, high contrast mode, and speech to text are some examples. Equally important is hardware support. One of the most commonly used pieces of hardware in the accessibility realm is something you probably already use — your keyboard.

Going Mouseless

Not everyone likes (or is able to use) a mouse for various reasons. Some of them include:

  • Abilities: Some users may not be able to use a standard mouse due to physical limitations, such as dexterity (unable to effectively move or click the mouse) or vision loss (unable to see the mouse cursor)
  • Comfort: Keyboards may be more pleasant to use for some people, especially those with chronic wrist pain caused by arthritis or Carpal Tunnel Syndrome
  • Efficiency: Power users can move more quickly and with greater accuracy using a keyboard
  • Alternative devices: Users with motor disabilities may prefer to map keyboard keys to other devices like switches or buttons, or may use tools like a mouth stick to interact with their touch screen or keyboard

Keyboards and Focus

It can help to think of focus as a keyboard equivalent of the mouse hover state. When navigating with a mouse, actionable HTML elements may receive some slightly different styles when the cursor moves over them. This indicates to the user user that they can perform some action on or within the element. For example, a when a user hovers over a button, the button’s background color might change from gray to blue to indicate to the user that they can click on the button to submit a form.

There is a similar, although more subtle feature for keyboards to indicate an actionable item, much like hover, but for keyboards. This is called focus.

Focus Style

Much like hover, you can tell when an element is receiving focus based on its appearance (CSS style). The default focus state varies between browsers.

For a button in Chrome and Safari, the focus indicator is a light blue glowing outline. In IE, it’s a dashed gray outline. In Firefox, it’s a bit of a combination of the two, with a blue border on the outside of the button and a dashed outline inset within the button.

The various default focus indicators
From left to right: A focused button in Safari on MacOS, followed by Chrome, Firefox, and Internet Explorer 11 on Windows 10.

A Note on Safari

At the time of writing, you must manually turn on the focus indicator in Safari. Coming from a Windows background, this tripped me up the first time I began testing keyboard accessibility on my Mac. To enable the focus indicator, open the Safari menu, then Preferences, and click on the Advanced tab, then check the option “Press tab to highlight each item on a webpage.”

Safari forces you to toggle a setting in order to see a focus indicator

Receiving Focus

Only one element may receive focus at one time. When the focus leaves an element, it is said to be “blurred.”

How does an element receive focus? There are several ways, although there are some exceptions for certain elements receiving focus depending on the browser:

  1. By hitting the tab key (move forward) or shift + tab (move backward)
  2. By being clicked
  3. By switching focus via JavaScript

Focusable Elements

Not all elements can (or should) receive focus. Generally, only elements that can be used to trigger an action or navigate the page should be focusable. Disabled elements and elements that are hidden do not receive focus.

Focusable elements can fall into two categories — semantic HTML elements and non-semantic HTML elements, which I will refer to as custom controls.

Semantic Focus

Certain semantic elements can receive focus by default, without any additional attributes or JavaScript. These semantically focusable elements include:

  • Buttons
  • Links
  • Input fields
  • Text areas
  • Checkboxes
  • Radio buttons
  • Areas (within image maps)

Custom Controls

Aside from the semantic elements, other elements like divs and spans can receive focus by assigning the tabindex attribute. A tabindex with a value of 0 will allow an element to appear normally in the tab order (more about this later).

A tabindex of -1 will only allow the element to receive focus programmatically through JavaScript. This means that the user will not be able to access the element while navigating the document through the normal tab order flow.

While the tabindex attribute can have positive values, you should avoid using positive values to manually manage your tab order, as it can be confusing.

Use non-semantic elements with caution, as they don’t provide the same native keyboard support as semantic elements without additional ARIA and JavaScript.


Much like the hover state, the focus state provides users with a clear visual indicator of where they are on the page and what action they are about to take, whether that’s clicking a link or submitting a form. Although its appearance may vary between browsers and websites, it is a necessity for those who do not use a mouse. Be sure to keep focus in mind while you design and develop websites.

This post is the first of two parts. Continue reading in part two, Four “Keys” to Better Keyboard Accessibility.