Test Your Website with the Keyboard in 15 Minutes

Here is a typical scenario: a physiotherapy practice launches a new website with online booking. Everything looks great, and appointments are coming in. Then a patient calls. She tried several times but simply couldn’t reach the “Book appointment” button. Because of tendinitis in her wrist, she is currently using her computer with the keyboard only.

Problems like this often go unnoticed because everyone on the team uses a mouse or trackpad. Yet you can find them in a few minutes, without testing software, plug-ins or any knowledge of code. All you need is a keyboard, a browser and a bit of discipline: the mouse stays where it is.

This article walks you through a five-round test that takes about 15 minutes. It doesn’t replace a full accessibility audit, but it uncovers exactly the issues that most often lock out people who don’t use a mouse: missing focus, illogical order, unreachable elements and traps you can’t get out of.

Why the test is worth it

Keyboard accessibility means that a website can be used entirely without a mouse or touchscreen. Far more people rely on this than you might think: people with motor impairments, people who use a screen reader, people who use voice control, switches or alternative keyboards. Add to that everyone with a temporary limitation, such as a broken arm, and power users who are simply faster with the keyboard.

Many of these assistive technologies work like a keyboard under the hood. So anything that can’t be reached by keyboard is often out of reach for them as well. That makes the keyboard test one of the most efficient tests there is: one pass indirectly covers several ways of using your site.

The WCAG (Web Content Accessibility Guidelines), the international standard for accessible web content, turn this into testable success criteria. The most important ones for this test are:

• 2.1.1 Keyboard (Level A): All functionality can be operated with a keyboard.
• 2.1.2 No Keyboard Trap (Level A): If you can move into an element with the keyboard, you can also move out of it.
• 2.4.1 Bypass Blocks (Level A): Repeated sections such as the navigation can be skipped.
• 2.4.3 Focus Order (Level A): The order in which elements receive focus preserves meaning and operability.
• 2.4.7 Focus Visible (Level AA): It is always clear where the focus is.
• 2.4.11 Focus Not Obscured (Minimum) (Level AA, new in WCAG 2.2): The focused element is not entirely hidden by other content, such as a sticky header or cookie banner.
• 3.2.1 On Focus (Level A): An element receiving focus does not by itself change the context, so it doesn’t open a new page, for example.

How often the basics are missing shows up in the annual “WebAIM Million” analysis of the home pages of the top one million websites. In the 2026 edition, only 17.1% of home pages had a skip link at all, and one in ten of those was broken. Automated tests detected WCAG failures on 95.9% of home pages. Keep in mind that automated tools can’t catch many keyboard issues. Whether the focus is visible or the order makes sense is something only a person can judge. That is exactly what this test is for.

For many businesses, this is also a legal matter. In Germany, for example, the Accessibility Strengthening Act (Barrierefreiheitsstärkungsgesetz, BFSG), which implements the European Accessibility Act, sets accessibility requirements for many digital products and services. Keyboard operation is one of the basics any accessible website is measured against.

Preparation: one minute

Before you start, make sure your browser actually makes full use of the keyboard. On Windows, the Tab key works right away in all common browsers. On a Mac, things are different:

• macOS: In System Settings, go to Keyboard and turn on “Keyboard navigation.” Otherwise, Tab in many apps only moves between text fields and lists, not between all controls.
• Safari: In addition, go to Safari, Settings, Advanced and turn on “Press Tab to highlight each item on a webpage.” Without this setting, Safari skips links when you tab, and you’ll either find problems that don’t exist or miss real ones.

Next, decide what you’re going to test. Fifteen minutes isn’t enough for a whole website, but it’s plenty for one important flow. Pick the one task the website exists for: buying a product, booking an appointment, sending an inquiry. For the physiotherapy practice, that’s “book a physiotherapy session.”

Also open a blank document for notes. Each problem gets one line: where it happens, what happens and why it gets in the way. Then push the mouse aside and don’t touch the trackpad.

The keys you need are few:

• Tab moves to the next interactive element, Shift + Tab moves back.
• Enter follows links and activates buttons.
• Space activates buttons, toggles checkboxes and scrolls the page when no control has focus.
• Arrow keys move within radio buttons, select lists, menus, tabs and sliders.
• Escape closes dialogs and expanded menus.

Round 1: Getting started (2 minutes)

Reload the home page and press Tab exactly once. What happens?

Does a skip link appear?

Ideally, a link such as “Skip to content” appears in the top left corner. It is usually hidden and only shows up on the first Tab. Press Enter and then Tab once more: the focus should now land in the main content, not back in the menu.

Why this matters: without a skip link, someone has to tab through the logo, main navigation, search field and language switcher on every single page before reaching the actual content. With a navigation of 20 links, that’s 20 key presses, on every page.

Can you see where you are?

This is the most important question of the entire test. After every Tab, it must be obvious which element is currently active. This is usually shown by an outline or highlight, known as the focus indicator.

A common reason it’s missing: at some point, someone added outline: none in the CSS because the outline looked “ugly” when clicking with the mouse. For keyboard users, the website is now like a screen without a mouse pointer. You press Tab and guess.

On the practice website, it looks like this:

Before: Nothing seems to happen on the first Tab. Only after the fourth Tab does a light gray, barely visible outline appear around a menu item. Where the first three key presses went remains a mystery.

After: The first Tab reveals the “Skip to content” link. Every focused element gets a bold, two-pixel outline in the dark brand color, with a little space around the element.

A focus indicator doesn’t have to be ugly. It deserves the same design attention as any other button state, ideally right in your design system. The CSS pseudo-class :focus-visible, for example, lets you show the outline for keyboard users only, not when clicking with the mouse.

Round 2: Navigation and header (3 minutes)

Now tab slowly through the header and main navigation. Pay attention to three things.

Can you reach everything?

Every menu item, the search field, the language switcher, the cart icon, the login: anything you can click with the mouse must also be reachable with Tab. If an element gets skipped, it’s often not a real link or button but a clickable div or span. Such elements respond to mouse clicks, but not to the keyboard.

Can you open submenus?

Dropdown menus that only open on mouse hover are a classic. Check whether a submenu opens with Enter, Space or an arrow key, and whether you can then reach its items. Just as important: Escape should close the menu again, and the focus should then return to the menu item that opened it.

A related issue is content that appears on focus, such as tooltips or mega menus. According to WCAG success criterion 1.4.13 (Level AA), it must be possible to dismiss such content without moving the focus, typically with Escape.

Does the mobile menu work?

Narrow the browser window until the hamburger menu appears, and test again. Bugs hide here surprisingly often: the menu button can’t be reached, the opened menu doesn’t receive focus, or the focus wanders invisibly through the page behind the menu.

That’s exactly what happened on the practice website: the “Services” submenu only opened on mouse hover. The “Physiotherapy” page couldn’t be reached by keyboard at all, only via a detour through the search.

Round 3: Order in the main content (3 minutes)

Now go through your chosen flow, which in the example means the “Physiotherapy” page and on to the booking. Watch the order in which the focus moves.

Does the focus follow the reading order?

The focus should move the way you read the page: top to bottom, and left to right within a row. If it suddenly jumps from the top of the page to the footer and back, the order in the code differs from the visual order.

This often happens when the layout has been rearranged with CSS, for instance using order in Flexbox or Grid, or when someone has set positive tabindex values. WebAIM explicitly advises against changing the order with a tabindex of 1 or higher. It’s better to fix the order in the HTML and handle the layout with CSS.

Do hidden elements receive focus?

Another warning sign: you press Tab, and the focus outline disappears for a few steps. Usually the focus has landed on elements that aren’t visible, such as links in a collapsed accordion, a hidden carousel slide or the closed mobile menu. That’s confusing for sighted keyboard users, and often even more so for screen reader users.

Is the focus hidden?

Since WCAG 2.2, there’s a dedicated criterion for this. Tab your way down a long page and watch for fixed elements: a sticky header, a chat bubble or a cookie banner that stays at the bottom of the screen can completely cover the focused element. The focus is technically there, but you can’t see it.

Before: On the “Physiotherapy” page, the booking widget sits in a box at the bottom. After you dismiss the cookie notice, it remains as a thin bar at the bottom edge and covers exactly that area. While tabbing, the focus disappears behind the bar.

After: The bar disappears completely once a choice is made. In addition, the CSS property scroll-padding-bottom ensures that focused elements don’t end up underneath fixed bars.

Round 4: Forms, dialogs and traps (4 minutes)

Now it gets serious. Forms, dialogs and interactive elements contain the most barriers, and this is where it’s decided whether someone can complete the task.

Filling in forms

Fill in the entire form using only the keyboard. Can you reach every field in a sensible order? Can you select radio buttons with the arrow keys and toggle checkboxes with Space? Can you open and operate select lists?

Custom-built elements are especially critical: date pickers, time slots, sliders, file uploads. They often look like native form elements but don’t behave like them. In the practice example, the available time slots were built as colored tiles that only responded to mouse clicks. When tabbing, the focus skipped the entire calendar.

A small but important check: simply focusing a field, or moving through the options of a select list with the arrow keys, must not trigger anything unexpected, such as an automatic submit or a page change. That’s what WCAG success criterion 3.2.1 requires. You’ll find more on good forms in the article Forms Nobody Abandons.

Triggering error messages

Deliberately leave a required field empty and submit the form. What happens to the focus? It’s good if it jumps to an error summary or directly to the first invalid field. It’s bad if the error message appears somewhere at the top while the focus stays on the button at the bottom. Without a mouse, you won’t even know there’s an error.

Opening and closing dialogs

Open every dialog that appears in the flow: confirmations, login windows, video overlays, image galleries. A dialog that sits on top of the page (the technical term is modal dialog) should behave like this:

• When it opens, the focus moves into the dialog.
• While it’s open, the focus stays inside the dialog. The page behind it can’t be reached.
• Escape closes the dialog.
• After closing, the focus returns to the element that opened the dialog.

If you use the HTML dialog element with the showModal() method, the browser gives you much of this for free: according to MDN, the rest of the page becomes inert, the focus moves into the dialog when it opens, and Escape closes it.

Looking for keyboard traps

A keyboard trap is an element you can tab into but not out of. Typical candidates are embedded content such as video players, maps, chat widgets, rich text editors and ad banners in an iframe. Test each of them: can you get back out with Tab and Shift + Tab? If not, Escape might help. If nothing works, you’ve found a trap that ends the visit for anyone without a mouse.

The opposite of a trap is a dialog that doesn’t hold the focus. That’s a bug too, just a different one: you end up tabbing invisibly through the dimmed page behind it while the dialog stays open.

Checking keyboard shortcuts

Some websites and web apps offer single-character keyboard shortcuts, such as “S” for search. These can clash with voice control when a spoken word accidentally triggers shortcuts. WCAG success criterion 2.1.4 (Level A) therefore requires that such shortcuts can be turned off, remapped, or are only active when the relevant element has focus.

Round 5: Evaluation (2 minutes)

To finish, answer one single question: could you have completed the task using only the keyboard? If not, that’s the most important finding of the entire test.

Then sort your notes by severity. A simple scale is enough:

• Blocking: The task can’t be completed. Examples: button unreachable, keyboard trap, calendar unusable.
• Hindering: It works, but only with effort or guesswork. Examples: focus barely visible, illogical order, no skip link.
• Annoying: Small issues that make the flow unnecessarily long. Examples: focus briefly lands on hidden elements, dialog doesn’t return focus.

For the practice website, the test revealed three blocking issues (submenu mouse-only, time slot tiles not focusable, booking area hidden) and two hindering ones (no visible focus, no skip link). That’s a manageable list the development team can work through in one sprint. With these 15 minutes, the patient would never have needed to call.

A tip for the handover: describe each problem with the page, the element and the key press, for example “Physiotherapy page, booking calendar: Tab skips all time slots.” That way, anyone can reproduce each bug right away without having to ask how you found it.

What the test doesn’t cover

The keyboard test is quick and revealing, but it has limits. It doesn’t tell you whether a screen reader announces elements in a meaningful way, whether images have alt text, whether contrast is sufficient or whether the content is easy to understand. Touch and voice control are only covered indirectly.

So treat it as a first filter. It finds the most serious barriers with little effort, and it’s easy to repeat. A good rhythm: run it on your most important flow before every major release, and whenever a new component such as a calendar or a dialog is added. For the next steps, from automated testing tools to screen reader testing, the article Accessibility Testing: Tools and Methods for UX Designers gives you an overview.

Conclusion

A meaningful accessibility test doesn’t require a budget or specialized tools. A keyboard and 15 minutes are enough to find out whether people without a mouse can use your website at all. The five rounds cover the points where things most often go wrong in practice: invisible focus, an order without logic, elements that only respond to mouse clicks, and dialogs or embedded content that swallow the focus.

The biggest gain, though, is the change in perspective. Once you’ve experienced what it feels like to get stuck in a menu or to tab blindly through a page, you design focus states, menus and dialogs differently. So it’s best not to run the test alone, but together with your team: one person types, everyone else watches.

Checklist

• The first Tab reveals a working skip link to the main content.
• The focus is clearly visible on every element.
• All links, buttons and form elements can be reached with Tab.
• Submenus open with the keyboard and close with Escape.
• The mobile menu also works with the keyboard.
• The focus order follows the visual reading order.
• Hidden elements don’t receive focus.
• No sticky header, banner or chat window covers the focused element.
• Forms can be filled in completely, and errors move the focus to the error message.
• Dialogs hold the focus, close with Escape and return the focus.
• There are no keyboard traps in videos, maps, widgets or iframes.
• The website’s core task can be completed with the keyboard alone.

Sources

• W3C WAI: Understanding Success Criterion 2.1.1: Keyboard
• W3C WAI: Understanding Success Criterion 2.1.2: No Keyboard Trap
• W3C WAI: Understanding Success Criterion 2.4.3: Focus Order
• W3C WAI: Understanding Success Criterion 2.4.7: Focus Visible
• W3C WAI: Understanding Success Criterion 2.4.11: Focus Not Obscured (Minimum)
• W3C WAI: How to Meet WCAG (Quick Reference)
• WebAIM: Keyboard Accessibility
• WebAIM: The WebAIM Million (2026)
• MDN Web Docs: The Dialog element
• Apple Support: Change Advanced settings in Safari on Mac
• Apple Support: Use your keyboard like a mouse on Mac