Keyboard Accessibility: What It Is and How to Test Your Website

Keyboard accessibility means every link, button, form field, menu and interactive feature on a website can be reached and operated with a keyboard alone, with a clear visual indicator showing where focus sits at each step. It is one of the first things an accessibility audit checks, because a website that fails here shuts out people who cannot use a mouse and for councils, NHS bodies and other organisations that rely on digital services for the public sector, it is also a legal requirement. This guide explains what it covers, which WCAG 2.2 criteria apply and how to test your own website.

The principle is simple, but the detail catches many organisations out. Custom menus, cookie banners, sliders and pop-up forms are often built for mouse users first, so keyboard support is added late or missed altogether.

In practice, a keyboard accessible website meets five conditions. The rest of this article explains each one in more detail.

• Every interactive element can be reached with the Tab key.
• Focus moves through the page in a logical order that matches the layout.
• A visible focus indicator shows which element is active at all times.
• Every control can be operated with standard keys such as Enter, Space, the arrow keys and Escape.
• Users can always move focus away from a component, so nothing traps them.

If any one of those conditions fails, a keyboard user may be unable to submit a form or book an appointment. That is why keyboard access is treated as a foundation of accessibility rather than a late refinement.

Who Relies on Keyboard Navigation

Keyboard navigation is used by a much wider group of people than many website owners expect. The W3C explanation of WCAG Success Criterion 2.1.1 Keyboard notes that keyboard operation makes content usable by people with no vision, who cannot use devices such as a mouse that need eye and hand coordination and by people who use alternative keyboards or input devices that act as keyboard emulators.

Those emulators include speech input software, sip-and-puff systems, on-screen keyboards and scanning software. People with motor conditions, tremors or repetitive strain injuries often find a keyboard more reliable than a mouse and some users with low vision find it easier than tracking a small pointer.

It is worth separating two terms that appear in the same search results. The accessibility keyboard settings on Mac, Windows, iPhone and Android control on-screen keyboards and other input options on the device itself. Website keyboard accessibility is different, because it concerns whether your pages respond properly to whatever keyboard or keyboard emulator the visitor is using.

Keyboard accessibility also overlaps with, but is not the same as, screen reader compatibility. Screen reader users rely on keyboard commands and on semantic markup that their software can interpret, while sighted keyboard users depend heavily on a visible focus indicator and a predictable order. A website needs to work for both groups and fixing one rarely fixes the other completely.

How Keyboard Navigation Works on a Website

Keyboard navigation works by moving focus from one interactive element to the next and then using a small set of standard keys to operate whatever has focus. Browsers handle much of this automatically for native HTML elements such as links, buttons and form fields, which is why semantic markup matters so much.

The WAI-ARIA Authoring Practices guide on developing a keyboard interface describes a convention common across platforms. The Tab and Shift + Tab keys move focus between components, while the arrow keys move focus inside components that contain several focusable items, such as radio groups, tab lists, menus and grids. The standard keys and what users expect from them are set out below.

Tab

Moves focus forward to the next link, button, form field or other interactive element in the page.

Shift + Tab

Moves focus back to the previous interactive element, so users can correct a mistake or return to a field.

Enter

Follows a link or activates a button, working in the same way as a mouse click.

Space

Activates buttons and toggles checkboxes. When no control has focus, it scrolls the page down.

Arrow keys

Move between options within a group such as radio buttons, tabs, menus or a select list.

Escape

Closes dialogs, menus and pop-ups, returning the user to where they were before.

Users build up strong expectations around these keys, so custom components should follow the same conventions. A dialog that ignores Escape, or a dropdown that needs Tab to move between options, forces users to learn a new pattern.

The WCAG 2.2 Success Criteria for Keyboard Access

Several success criteria in WCAG 2.2 deal directly with keyboard access and focus and most of them sit at Level A, the most basic level of conformance. The table below lists the criteria that matter most for a typical organisational website.

Focus Not Obscured (Minimum) is one of the criteria introduced in WCAG 2.2 and it targets a common modern problem. The W3C guidance on Success Criterion 2.4.11 requires that a component receiving focus is not entirely hidden by author-created content, so sticky headers, chat widgets and cookie banners must not cover the element a user has just tabbed to.

Visibility of the focus indicator also depends on contrast. The W3C notes in its explanation of Non-text Contrast that, in combination with Focus Visible, the focus indicator must have sufficient contrast against the adjacent background and its examples use a 3:1 ratio. Organisations aiming higher can look at Focus Appearance, a Level AAA criterion that sets out a minimum size and contrast for the indicator itself.

Why Keyboard Access Matters for Public Sector and B2B Websites

Keyboard access matters because it is a legal obligation for public bodies and a practical expectation for everyone else. The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 require public sector websites and apps to be accessible and to publish an accessibility statement.

The government’s guidance on accessibility requirements for public sector websites and apps states that bodies meet the legal requirements by meeting the WCAG 2.2 AA standard and publishing that statement. The same guidance explains that the Government Digital Service monitors compliance by examining a sample of public sector websites and mobile apps every year. Because most keyboard criteria sit at Level A, a keyboard failure is usually one of the more serious findings in any audit or monitoring report.

Private organisations are not covered by those regulations, but the gov.uk guidance also confirms that all UK service providers have a legal obligation to make reasonable adjustments under the Equality Act 2010. For B2B suppliers there is a commercial angle too, since public sector and large enterprise buyers often ask for accessibility statements and evidence of WCAG conformance during procurement.

Common Keyboard Accessibility Failures

Most keyboard problems come from custom components that replace native HTML elements or from styling that removes default browser behaviour. The four failures below appear on many otherwise polished websites.

The MDN reference for the tabindex attribute recommends using only the values 0 and -1 and advises against values greater than 0 and CSS properties that change the order of focusable elements. It also warns against adding tabindex to a div to imitate a button, when the native button element already provides focus and keyboard behaviour without extra code.

Two further failures are common on public sector websites. Focus that lands behind a sticky header or cookie banner breaks Focus Not Obscured and dialogs that do not return focus to their trigger button leave users lost on the page.

How to Test Keyboard Accessibility on Your Website

The quickest keyboard accessibility test is to put the mouse aside and try to complete your most important journeys using only the keyboard. It needs no specialist software and catches problems that automated tools regularly miss.

The GOV.UK Service Manual page on testing for accessibility recommends both automated and manual testing, warning that teams will miss some issues if they rely on automated testing alone. It names tools such as Axe and WAVE for automated checks and lists lack of keyboard accessibility as one of the common problems a basic manual check should look for. A simple manual test follows the steps below.

Record each problem against the relevant success criterion and note the page and component where it occurred. WebAIM’s guide to keyboard accessibility includes a useful reference table of expected keystrokes for common interface elements, which helps when judging whether a custom widget behaves as it should.

Manual testing is not a replacement for a full audit, particularly on large public sector websites with many templates and embeds. A formal review also tests with screen readers and checks issues a keyboard pass cannot reveal, such as missing labels.

Keyboard Accessibility in WordPress

WordPress core provides a reasonable starting point for keyboard access, but the theme and plugins decide whether a website keeps it. The WordPress theme review team’s accessibility-ready requirements include a skip to content link, keyboard navigation support and sufficient colour contrast of text and UI controls, which shows how central keyboard access is to an accessible theme.

Problems usually arrive through custom navigation menus that only open on hover, image sliders and carousels that trap focus, modal windows that do not manage focus correctly and custom form elements that replace native inputs. Page builders and premade themes can add further barriers deep in the generated markup, which are hard to correct without rewriting components.

Priority Pixels builds WordPress websites by hand without page builders or templates, using an in-house framework optimised for accessibility, security and long-term support. Our WordPress development for B2B and public sector organisations treats keyboard navigation, semantic HTML and focus management as part of the build rather than a fix applied after launch.

Building Keyboard Access Into Public Sector Websites

The most reliable way to achieve keyboard accessibility is to plan for it from the first wireframe and keep checking it as content changes. Retrofitting keyboard support to finished components is usually slower, because the underlying markup often has to change.

Priority Pixels designs and develops all WordPress websites to WCAG 2.2 AA as a minimum and prototyping includes testing with keyboard navigation and screen reader simulation before development begins. During our website accessibility audits and remediation, we assess keyboard operability, screen reader compatibility and focus management, then rank issues by impact and legal risk so the most serious problems are fixed first. Remediation work typically includes fixing keyboard navigation and making sure focus indicators are visible and logical throughout the website.

Ongoing monitoring matters just as much on public sector websites, where many editors publish content and new embeds appear regularly. We provide accessibility monitoring after launch and WordPress training so internal teams can maintain standards for routine publishing. Our guide to accessibility requirements for public sector websites covers the wider compliance picture and our article on the latest version of WCAG explains what changed in WCAG 2.2 and why it matters for your accessibility statement.