Keyboard-only accessibility testing

Whilst this is a simple check to do, it actually covers several WCAG criteria because is such a core accessibility concern.

Mac users

For Mac check system settings for enabling tabbing

System Preferences > Keyboard > Shortcuts > check “Use keyboard navigation to move focus between controls”


Use the tab key to navigate around just the interactive elements on the page. You can use enter or space to activate buttons and enter to activate links. Some components might require arrow keys - radio button groups show focus on tab and then you can use space to select that radio or use arrow keys to move up and down the list.

Check if there is a skip link - an in-page link at the top of the page which takes you to the main content and means you don't have to tab-key your way through all the primary navigation on every page.

Do all the things which allow interaction (link, buttons, form elements etc) get focus when you tab to them?

Can you reach everything you can interact with using a mouse with your keyboard instead?

Website with a button highlighted in the page and in the devtools. DevTools shows the button has a tabindex set to minus 1
The Trainline website showing controls which cannot be reached by keyboard. In this case it is due to use of a negative tabindex

Seeing where your focus is

Keyboard use relies heavily on being able to see where the focus currently is. If this is taken away by css or obscured (or just forgotten about) it can make it very difficult to work out where you are on the page. Making focus states really obvious (and importantly contrast well against non-focus states) helps as focus can jump across large sections of the page.

Is there a good focus indicator for all the interactive content? Something which catches your eye easily so you can find it on a page.

If you can't see where the focus went, you need to check if this is just down to a poor focus state or because the focus has gone to content which has been hidden from view - something you will often find when content has been hidden off-screen until triggered (like a menu).

A website with a focus shown floating in the middle of the page, apparently on nothing. Another screenshot shows there is a hidden menu which has got the focus.
A car dealer site showing how focus has gone to a hidden ‘mega-menu’ which is full of links. Whilst this will cause confusion in hiding the focus, it also shows it hasn’t been hidden correctly. This means keyboard users will have to tab through a lot of links to get to some of the primary navigation options.

Make sure you check the page in both desktop and mobile/tablet view. External keyboards are commonly paired to smaller devices and desktops can display the mobile view when the page is zoomed. Keyboards are often ignored when designing for mobile unfortunately.

The Marks and Spencer homepage in tablet view with an icon shown forced to focus state but with no indicator visible
M&S website’s menu icon has no focus indicator

Logical order

Does the order in which the links, buttons etc get focus make sense? It is all too easy to use css like grid to change the visual order of content, or use html like tabindex to force the focus order without checking how this affects other users. A focus indicator jumping around a page haphazardly can be confusing or frustrating for a user.

Keyboard traps, where you find you cannot tab out of a component are not something you normally want. But occasionally they are desirable, like in the case of a modal dialog (often visually indicated by a dimming of the page behind it). With a dialog like this you want to keep the user within the dialog until they make some sort of decision and not to be able to break out and navigate the page behind.

Testing order with Firefox

You can test focus order visually using Firefox’s tab order option in developer tools. This will overlay numbers on the page showing where the focus will be placed.

Firefox's devtools showing the accessibility panel
The “Show Tabbing Order” option in Firefox’s Accessibility panel of devTools.
Morrisons supermarket homepage with numbers overlaid showing where the focus lands and in what order
Morrisons website showing the Firefox “Show Tabbing Order” in action

Testing order with activeElement

Overlays like Firefox’s are good but it can be tricky to track down a disappearing focus, especially in a crowded interface. You can be more targeted by using activeElement in the console. In Chrome’s console select Create live expression (the eye icon) and add document.activeElement. This will create a snippet which will follow focus in the page and allow you to both see where the focus is and what elements it is actually focussed on.

Thomas Cook website with an element highlighted on the page and devtools open showing the element and class list of the item which currently has focus.
activeElement in use showing where the focus lies, despite no visible focus on the page itself

Managing focus

By this we mean, when focus is moved (not by the user), how is it handled? For example, clicking on a close icon in a dialog means you will be removing that icon from the page (as it is part of the dialog), so where does the focus end up? By default it goes back to the top of the page when an element is no longer present. In this case the focus needs to be managed to make a better user experience.

Focus affects screen-reader users too - especially when it is moved as a result of an action. Screen-magnification users can also set their view to follow the focus, so ensuring focus is managed well is also very important for these groups.

In our dialog example we'd want focus to be returned to the thing which triggered the dialog, or if the dialog wasn't triggered by the user clicking something, back to whatever the user had focus on when it appeared. The trick is to try and be logical about it and keep it close to where the user's attention is.

The more dynamic the page the more focus management will be needed and the more important keyboard testing becomes.

Checking everything works

As most developers build and test with a mouse it is all too easy to forget that not everyone can (or wants to) use one. So you can find buttons which only respond to a mouse click, effectively blocking a user from continuing.

So, can you complete the task with just a keyboard? At the most basic level this means can the user activate all the links, buttons and other interactive elements (including things like video players) on the page and complete any forms.

If you have any scrollable areas then make sure these can gain focus themselves to allow a keyboard user to be able to scroll the content, otherwise the content inside might not be reachable.