Short answer: Keyboard navigation means people can use your whole site with Tab, Shift+Tab, Enter and Esc. Check that every link, menu and form works without a mouse, that the focus always shows and that a skip link jumps past the menu.
Who uses the keyboard to browse
The W3C mentions people with no vision, who can’t use a mouse that needs eye-hand coordination, and people who use alternate keyboards. Speech input, on-screen keyboards and sip-and-puff devices also reach a page as if they were a keyboard.
People with low vision may find a pointer hard to follow, and some people simply prefer the keyboard because it is faster. For all of them the page is a sequence: they reach a link only after the ones before it.
What the accessibility rules ask
| Criterion | Level | What it asks |
|---|---|---|
| 2.1.1 Keyboard | A | Everything can be done with a keyboard, except freehand movements |
| 2.1.2 No keyboard trap | A | Keyboard users don’t get stuck |
| 2.4.1 Bypass blocks | A | A way to skip content repeated on every page |
| 2.4.3 Focus order | A | Elements get the focus in an order that keeps the meaning |
| 2.4.7 Focus visible | AA | Each element that gets the focus shows it |
| 2.4.11 Focus not obscured | AA | The focused element stays at least partly visible |
Names and levels from WCAG 2.2, read November 4, 2026.
Our ADA website compliance guide covers where these criteria fit in the law.
How to test your site with the keyboard
- Click the address bar, then take your hand off the mouse.
- Press Tab to move forward and Shift+Tab to go back.
- Check that you can see where the focus is at every step.
- Check that the order follows the reading order: left to right, top to bottom.
- Open every menu and dialog, use every form, and close what you opened with Esc or its close button.
- Press Enter on the skip link, then Tab: the focus should land in the content.
- Check that no sticky header, chat button or cookie notice hides the focus.
web.dev suggests tabbing through your pages before each publish. Our accessibility checker guide covers the automated tools that complement this test.
The focus indicator
Browsers draw a focus ring by default, and some sites remove it because they find it ugly. NN/g calls removing it catastrophic for keyboard users: if you don’t like it, replace it with one that fits your design.
With the :focus-visible selector, the ring shows when the browser decides the focus should be evident, usually with the keyboard, and not on every mouse click. The W3C adds that it must stay visible while the element has the focus.
The W3C also applies its contrast rules for non-text elements to the ring, so it has to stand out from the background around it.
Skip links and focus order
On most sites the menu comes first, so a keyboard user may press Tab dozens of times before reaching the content. The W3C notes that this can take a long time and may cause severe physical pain for some users.
A skip link at the top solves it, and it can stay hidden until someone tabs to it. NN/g warns that the step after Enter is often overlooked: the next Tab has to continue inside the content.
For the order, web.dev recommends arranging the HTML in the order the focus should follow, instead of moving elements with CSS. Closed menus and hidden panels should leave the tab order, with display: none or visibility: hidden.
What we found on our own site
On November 4, 2026, we went through five of our pages with the keyboard only: the home, a guide, pricing, contact and the Spanish home. A full pass took between 95 and 117 Tab stops per page.
Every stop showed a focus indicator; on the home’s blog list it outlines the whole card. The focus never got stuck, and the services menu opens with Enter, closes with Esc and gives the focus back to its button.
The first failure was the step NN/g warns about. On our home, “Skip to main content” did nothing, because our smooth-scroll script moved the page without moving the focus. We fixed it that morning, and the next Tab now lands in the content.
The second came from our cookie notice. On a first visit, the first Tab lands on it, and the skip links come right after it. While the notice was still open, some links we tabbed to ended up entirely behind it: between 10 and 18 per page on a phone. The W3C gives cookie banners as an example of this failure. We fixed it that morning: each focused element now scrolls clear of the notice, the chat button and the header, and none ended up hidden behind the notice afterwards.
Before you call a page keyboard-friendly
- Every link, button, menu and form works with the keyboard alone.
- The focus can leave every part of the page, dialogs included.
- A skip link jumps past the menu, and the next Tab stays in the content.
- The focus order follows the reading order.
- The focus indicator shows on every element that gets the focus.
- No sticky element hides the focused element.
RememberIf you can’t see where the focus is, neither can your visitors. Tab through every page before you publish it.
Before we call a page done, our web design team tests it with a keyboard, a screen reader and automated checks.
Quick answers about keyboard navigation
What is keyboard navigation?
Using a website with the keyboard alone: Tab moves forward through links, buttons and fields, Shift+Tab moves back, and Enter follows a link. People who can’t use a mouse depend on it, and some people simply prefer it because it is faster.
What is a skip link?
A link at the start of the page that jumps past the menu to the main content. It often appears only when someone tabs to it. After Enter, the next Tab has to land in the content, not back in the menu.
What is a focus indicator?
The visible mark, usually an outline, that shows which element has the keyboard focus. Browsers draw one by default. Removing it without a replacement leaves keyboard users unable to see where they are on the page.
What is a keyboard trap?
A part of a page that the focus can enter but not leave with the keyboard, such as an embedded widget. A dialog may hold the focus while it is open, as long as people know how to get out, usually with Esc.
How do I test my site’s keyboard navigation?
Click the address bar, put the mouse aside and press Tab through the whole page. Check that you always see the focus, that the order follows the reading order, and that every menu, form and dialog opens, works and closes.
Sources
Read on November 4, 2026. W3C Web Accessibility Initiative: Understanding Success Criterion 2.1.1: Keyboard, Understanding Success Criterion 2.1.2: No Keyboard Trap, Understanding Success Criterion 2.4.1: Bypass Blocks, Understanding Success Criterion 2.4.3: Focus Order, Understanding Success Criterion 2.4.7: Focus Visible and Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum). NN/g: Keyboard-Only Navigation for Improved Accessibility. web.dev: Keyboard access fundamentals. MDN: :focus-visible CSS pseudo-class. Our case: our own pages used with the keyboard only in a browser on November 4, 2026.