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

If you are a Mac user, oddly tabbing to navigate links and form controls in a webpage is turned off by default. This affects Firefox and Safari.

How to enable tab navigation on Mac


To fix Firefox you need to go make a change in the Mac system settings.

Before OS 13 it is in System Preferences > Keyboard > Shortcuts and check “Use keyboard navigation to move focus between controls”.

For OS 13 on it is in System Preferences > Keyboard and toggle on “Keyboard navigation”.

Mac OS Ventura keyboard settings showing the location of the tab navigation option


For Safari you need to make a change to Safari's own settings. In Safari > Settings > Advanced, check the option “press Tab to highlight each item on a web page”.

Safari settings showing the location of the tab navigation option


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. See larger image (new tab).

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. See larger image (new tab).

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. See larger image (new tab).

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. See larger image (new tab).
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. See larger image (new tab).

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. See larger image (new tab).

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? Browsers do try to help with this when an element is removed, but as this doesn't account for screen‐readers, the focus needs to be managed to make a better user experience.

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.