Keyboard navigation and accessibility testing

Every interactive element on a website must be operable using a keyboard alone — links, buttons, form fields, menus, sliders, date pickers. That means a logical order, with a visible indication of which element currently has focus. This is one of the most common accessibility failures on otherwise well-built ordinary business sites. Much of the visible testing during a build happens with a mouse. So keyboard-only failures go unnoticed.

What full keyboard navigation and keyboard accessibility actually requires

Requirement	What it means in practice
Every interactive element is reachable	Tab key moves focus forward through all links, buttons and form fields; Shift+Tab moves back
Every element can be activated without a mouse	Enter or Space activates a focused button or link
Focus order is logical	Tabbing follows the visual and reading order of the page, not a scrambled order set by the underlying code
Focus is visible	A clear visual indicator (commonly an outline) shows which element currently has keyboard focus
No keyboard traps	A user can always tab out of any component they tabbed into

Why custom-built interactive tab elements are where this most often breaks

Standard HTML elements are keyboard accessible by default — a native button, a native link, a native form field — because browsers implement that behaviour automatically. The failures concentrate in custom-built interactive components instead: a dropdown menu built from styled generic containers rather than native form controls, a custom date picker, an image carousel, or a modal dialog. Each of these needs keyboard behaviour explicitly built in by the developer. It is frequently skipped because the component visually works fine with a mouse, and nobody tests it any other way.

A custom component’s keyboard behaviour is most often wired up using the tabindex attribute. tabindex="0" makes an otherwise non-interactive element reachable in the natural tab order. Small positive tabindex values are widely discouraged because they override that natural order rather than following it. This is a common cause of the “jumps confusingly around the page” failure described further down this page.

Focus indicators and keyboard focus, and why removing them is a common but serious mistake

Many design systems remove the browser’s default focus outline for visual reasons. It’s often considered an unattractive blue or dotted box that clashes with a design’s aesthetic. Removing it without replacing it with an equally visible custom indicator leaves a keyboard user with no way to see where they currently are on the page. That functionally breaks keyboard navigation, even if every element is technically still reachable and operable. If a focus outline is removed for design reasons, a clearly visible custom replacement is not optional.

Keyboard traps — a more severe failure for keyboard users worth specifically checking for

A keyboard trap occurs when a user can tab into a component but cannot tab back out of it using standard keyboard commands. It’s commonly a poorly implemented modal window, embedded widget, or third-party plugin. This effectively strands the user and forces a page reload to recover. It is one of the more serious keyboard failures. It doesn’t just make a feature hard to use — it can block a user from the rest of the site entirely. Test any modal, popup or embedded widget specifically for this.

How to test your own site using keyboard tabindex and the spacebar in two minutes

Put your mouse aside entirely. Starting from your homepage, use only Tab, Shift+Tab, Enter and Space to navigate. Try to reach your main navigation, open any menu, and complete your contact form using only the keyboard. If you get stuck, cannot tell where you are on the page, or cannot escape a component, you’ve found a genuine keyboard accessibility failure. It is verified without needing any specialist tool or knowledge.

Why this test is more reliable than it sounds

Many WCAG success criteria require nuanced human judgement to assess properly. Keyboard operability is different. It is close to binary and directly testable by anyone. Either you can complete a task with only a keyboard, or you cannot. This makes it one of the more accessible checks for a non-technical business owner to perform on their own site, without waiting for a specialist audit.

What to ask a supplier about tabindex values

Ask directly whether every custom-built interactive component — menus, sliders, modals, date pickers — has been tested for keyboard operability, not just visually reviewed with a mouse. Ask specifically about any third-party widgets or embedded tools too. These sit outside the developer’s own code and can introduce keyboard traps they didn’t build and may not have tested.

Skip links, and why their absence matters more than it seems

A “skip to main content” link is often visually hidden until it receives keyboard focus. It lets a keyboard user bypass repeated navigation menus and jump straight to a page’s main content. Without it, that user has to tab through the same header links on every single page of a visit. Its absence is a minor inconvenience on a single-page visit. Across a multi-page browsing session it becomes genuinely significant. The repeated navigation tabbing compounds with every page load.

Why touch, switch-access devices, and website keyboard input raise related but distinct considerations

Keyboard operability is closely related to, but not identical with, operability by other assistive input devices. Switch-access systems are one example, used by some people with significant motor disabilities. They often rely on the same underlying keyboard-accessible interface. Building genuine keyboard support tends to substantially improve compatibility with these other input methods as a byproduct. That is a further reason keyboard testing is one of the higher-leverage checks a business can perform.

What “logical order” means when a page has a complex layout

For a straightforward, single-column page, logical tab order usually matches visual reading order without much extra thought. A page with a more complex layout is different: multiple columns, a sidebar, overlapping components. Here the underlying code order and the visual order can diverge without careful attention. This produces a tab sequence that jumps confusingly around the page, even though each individual element is technically reachable. Test this explicitly on any page with a non-trivial layout, not just simple ones.

What to do next

Run the two-minute keyboard test on your own site today, focusing especially on any custom menus, sliders or pop-ups. Where this discipline sits within a build more generally is covered on development as an ongoing engagement.