Keyboard Navigation Check

Many people navigate the web entirely by keyboard — users with motor impairments, screen-reader users, and power users. If a control can only be reached or activated with a mouse, it does not exist for them. VitalSite checks keyboard operability with axe-core, mapped to WCAG 2.1 success criterion 2.1.1 (Keyboard).

What VitalSite checks

• Focusable interactive elements. Links, buttons and controls must be reachable with the Tab key and activatable with Enter or Space.
• No keyboard traps. Focus must never get stuck inside a widget with no keyboard way out.
• Visible focus. Interactive elements should show a visible focus indicator so keyboard users can see where they are.

Why it matters

Keyboard access is the foundation of accessibility — screen readers, switch devices and voice control all rely on the same underlying keyboard operability. A <div> used as a button is the classic failure: it looks clickable but is invisible to the keyboard. Fixing this unlocks your site for a whole class of users at once.

How to fix it

• Use native interactive elements. <button> and <a href> are keyboard-operable for free; a clickable <div> is not.
• Never remove focus outlines without providing a clear replacement — outline: none with no alternative strands keyboard users.
• Test it yourself. Put the mouse away and Tab through the page: you should reach and use everything, in a logical order.

Verify the fix

Re-scan your domain, then tab through the page manually. The Keyboard Navigation check flags non-focusable controls and missing focus indicators; a manual pass confirms the order makes sense.

Run a free full-domain scan to see whether this affects your site — every page, with an exact fix guide. Pro and Agency plans add PDF export and monitoring.