Keyboard Accessibility in Four Words

Close up view of a computer keyboard.

Automated testing tools are great things to have in your web accessibility testing toolbox. But no automated tool can find every possible accessibility barrier on your page or site. There are certain tests you must perform manually. Testing your site by navigating using only your keyboard is one of the most essential (and easiest!) manual tests you should be doing.

If someone can interact with something on your webpage with a mouse, they should be able to interact with that thing if they’re only using a keyboard, too. Every interactive element needs to be reachable, visible, and usable, and the order that you move through them should be logical.

Definitions

  • Element: An individual component of your webpage. Can be interactive or non-interactive. Examples include: Headings, paragraphs, lists, hyperlinks, images, buttons, menus, widgets, etc.
  • Keyboard Focus: Refers to when an interactive element is reached by keyboard navigation. When this occurs, we say the element “receives focus” or “is focused.”
  • Focus Indicator: A visible marker showing which element currently has keyboard focus.

Reachable

Every interactive element on your page — like buttons, links, form fields, and menus — all need to be reachable. If someone can’t even get to the interactive elements in the first place, then how could they ever use them?

The easiest way to test for this is to use the TAB key on your keyboard. Each time you press TAB, you move to the next interactive element on your page in order. To go backwards, press SHIFT + TAB. Easy, right?

To fully test your webpage, just keep hitting TAB to move through the whole page one element at a time. Can you get to every single interactive element? If you can’t, then neither can anyone else!

Taking this one step further, every interactive part of every element also needs to be reachable. Some elements — like menus, check boxes, radio buttons, and tab panels — often contain groups of other smaller elements and need to be tested for an additional layer of navigation. They should be reachable using TAB like normal, but once they have focus you should be able to navigate to each individual interactive element inside them using your keyboard’s arrow keys .

For example, in the image below, the Services menu was first focused using TAB, then the Video Game Development menu item was focused using the down arrow key .

A fake website menu has three main navigation menus: Home, Services, and Resources. The Services menu is open and contains three menu items: Oil Changes, Apple Picking, and Video Game Development. Video Game Development is currently focused.
What in the world is this website for?!

Visible

While testing, you might run into a situation where you hit TAB, but you can’t see where you are on the page anymore. This usually happens when the focus indicator isn’t visible anymore — or wasn’t visible to begin with. Yikes! Beyond being reachable, every interactive element needs to have a visible focus indicator, too.

The good news is that web browsers have a built in focus indicator that works by default. The bad news is that many web developers don’t like the visual style of the default focus indicator or they may not even know it exists. So, they may end up modifying the way it looks or even removing it entirely, sometimes by complete accident.

There are many ways to design an accessible visible focus indicator, but one of the easiest and most common ways is to have an outline appear around the focused element. This clearly indicates to people who use a keyboard to navigate your site which element currently has focus. They can then visually track where they are on the page without getting lost.

"Web Accessibility Tips" button
This button is currently focused and has a clearly visible focus indicator — the black dashed outline.

Websites and applications often use some kind of visible change to indicate when the mouse pointer is on an element. For example, navigation menu items and buttons commonly change or reverse their colors, and links may change color or become underlined. Ideally, this same behavior will occur when someone navigates to those items using a keyboard, too.

Now, you might be asking yourself, “But why would someone who is blind need a visible focus indicator in the first place?” And the answer is, they probably don’t! If they’re using a screen reader, it will read the name of the element out loud when the element receives focus. But, there are many sighted people that still use a keyboard (or other assistive technology that sends keyboard commands) to navigate digital content, like a website. They may even use a screen reader, too. You need to think of the needs of everyone that might view your site so that you don’t accidentally leave people out.

Usable

So, at this point we’ve made sure that people can get to each element and that they know where they are on the page. Great! The next step is to make sure that each interactive element actually works the way it is supposed to and works without needing to use a mouse.

Imagine that you’ve just spent twenty minutes filling out a form on a webpage. All of the form fields worked as you expected them to… until you got to the “Submit” button. It doesn’t work. You desperately try again and again, getting more and more frustrated and/or confused. And understandably so! You eventually get so mad that you ask someone else for help. To your astonishment, they click the “Submit” button with the mouse and it works! It was only broken for keyboard users like you.

A man staring frustratingly at his computer holds his head in his hands. He is blowing out a slow sigh which is causing his cheeks to be puffed out.
Your website shouldn’t do this to people.

Unfortunately, this kind of situation happens all the time to people with disabilities. Thankfully, now that you know about it, you can work to prevent this kind of thing from happening to someone ever again.

Some common keyboard behaviors to test for include:

  • ENTER or SPACE should activate a button
  • ENTER should activate a link
  • SPACE should select and de-select checkboxes and select radio button options
  • ESC should exit a menu and close tooltips

Logical

Now that you’ve checked that each interactive element is reachable, visible, and usable, the last step is to make sure that their navigation order is logical. Every interactive element should receive focus in a consistent order that makes sense for the page. In other words, focus should move from one element to the next without randomly skipping around.

This logical order of navigation is often referred to as the TAB order. It is critical that the TAB order always matches the intended reading order of the page. However, this doesn’t mean that it always has to match the visual order of the elements on the screen. It will make sense for the TAB order and visual order to match most of the time, but you can deviate from matching the visual order if it makes sense to do so.

Recap

The following should apply to every single interactive element on your web page:

  • You can get to all of them
  • You always know which one is focused
  • They all work as expected
  • They are all in an order that makes sense