Keyboard Accessibility Testing: A 20-Minute Guide (2026)

You built a clean interface. The buttons sit where people expect them, the signup converts, the flow feels tight. Then someone tries to use it without a mouse and half of it falls apart. The custom dropdown will not open. A modal traps them on the page behind it. The focus ring disappeared two redesigns ago, so they cannot even tell where they are on the screen.

Keyboard accessibility is one of the most common places SaaS products break, and one of the easiest to test yourself. You do not need a screen reader, a lab, or a specialist. You need your keyboard and about twenty minutes. This guide covers what to test, how to test it, and how to read what you find.

Who actually navigates by keyboard

It is tempting to treat keyboard support as an edge case. It is not.

People with motor disabilities often cannot use a mouse or trackpad precisely, so they rely on the keyboard or on switch devices that emulate keyboard input. People who are blind use screen readers, and screen reader users move through a page almost entirely with the keyboard. Plenty of sighted people with no disability at all live on the keyboard because it is faster: they Tab through forms and hit Enter to submit rather than reaching for the mouse.

There is also a compliance angle. "Keyboard" is success criterion 2.1.1 in the Web Content Accessibility Guidelines, and it sits at Level A, the most basic tier. If your product fails keyboard access, it fails the floor of accessibility, not some advanced requirement. For the wider legal and standards picture, see our guide to running an accessibility audit for SaaS.

The keys that do the work

Before you test, know what each key is supposed to do. A conforming interface follows these conventions:

• Tab moves focus forward to the next interactive element. Shift + Tab moves it back.
• Enter activates links and buttons, and usually submits a form.
• Space activates buttons and toggles checkboxes. In a scrollable area it also pages down, which is why buttons should respond to Space.
• Arrow keys move within a component: options in a menu, tabs in a tab set, radio buttons in a group, a slider value.
• Escape closes the thing that is open: a modal, a dropdown, a popover.

The pattern to remember: Tab moves between components, arrow keys move within one. A native select, a set of radio buttons, and a proper menu all work this way. When your custom version does not, keyboard users notice immediately.

The twenty-minute keyboard test

Here is the whole test. Put the mouse aside. Actually move it out of reach, because the temptation to grab it is strong.

1. Load your most important flow. For most SaaS products that is signup through to the first real action inside the product. Start at the top of the page.
2. Press Tab and watch where focus lands. You should always be able to see which element is focused. Keep tabbing. Note the order: does focus move in a sensible reading sequence, roughly left to right and top to bottom, or does it jump around?
3. Reach every interactive element. Every link, button, field, checkbox, and control that a mouse can use must be reachable by Tab. If you can click it but cannot Tab to it, that is a failure.
4. Activate things. Use Enter and Space on buttons and links. Fill in the form fields. Toggle the checkboxes. Everything a click does, a keypress should do.
5. Open a dropdown or menu and use the arrow keys. Then press Escape. It should close and return focus to the control that opened it.
6. Open a modal. Focus should move into the modal when it opens. While it is open, Tab should cycle through the modal only, never slipping to the page behind it. Escape should close it and send focus back to where you were.
7. Check nothing is a trap. You should be able to Tab into a component and Tab back out. If focus gets stuck inside a widget with no way out except the mouse, you have found a keyboard trap, which is its own WCAG failure.

Write down what breaks as you go. Most teams find three or four issues in the first pass, and they are usually the same few culprits.

What good focus looks like

The single most common keyboard problem is invisible focus. A designer removes the browser's default outline because it clashes with the visual style, and no visible replacement gets added. Now a keyboard user is tabbing blind.

The fix is not to leave the ugly default outline everywhere. The fix is to make sure a clear, visible focus style exists on every interactive element. WCAG 2.2 tightened this with two criteria worth knowing. Focus Visible (2.4.7) requires that the focused element has a visible indicator. Focus Not Obscured (2.4.11, new in 2.2) requires that the focused element is not hidden behind a sticky header, a cookie banner, or a chat widget when it receives focus.

A good focus indicator has real contrast against its background and a clear shape, usually an outline or ring with a couple of pixels of thickness. If you can glance at the screen and instantly say where focus is, it works. If you have to hunt for it, it does not.

Where custom components break

Native HTML elements come with keyboard support for free. A real button, a real link, a real select, a real checkbox all work with the keyboard the moment you use them. Problems almost always start when a team rebuilds these from plain div and span elements for styling reasons.

A div styled to look like a button is not a button. It is not in the tab order, it does not respond to Enter or Space, and a screen reader does not announce it as a button. Making it work means adding a tabindex, wiring up key handlers, and setting the right ARIA role, which is a lot of effort to recreate what a button element already does.

The highest-value rule in keyboard accessibility is boring: use the native element. Reach for a real button, a real anchor, a real input first. Only build a custom widget when the platform genuinely has no equivalent, and when you do, follow the established keyboard pattern for that widget rather than inventing one.

The failures you will probably find

None of these are exotic. They are the everyday failures that ship because nobody put the mouse down and tabbed through the product before release.

Fitting this into your process

Keyboard testing is cheap enough to do often, so do it often. The practical move is to run the twenty-minute test on your primary flow before every significant release, and to add "reachable and operable by keyboard" to the definition of done for any new interactive component. Catching a keyboard trap in a pull request review costs minutes. Catching it after a customer files a complaint costs a lot more.

Automated tools help, but only to a point. Scanners like axe and WAVE are excellent at catching missing labels and contrast issues, and you should run them. What they cannot reliably tell you is whether the tab order makes sense, whether a modal traps focus correctly, or whether your custom menu responds to arrow keys. Those need a human at the keyboard. Keyboard access is closely tied to mobile usability too, since focus order and target sizes matter on every device. Our mobile UX audit guide covers the overlap.

The takeaway is simple. If your product works with a keyboard, it works for a much wider group of people, and it usually means the underlying markup is healthy. If it does not, you will not find out from a design review. You find out by tabbing through it.

Want a fast read on where you stand before the manual test? Run a free UX audit with UXAuditPro. It scores accessibility as one of seven dimensions and flags the common issues, which makes a good starting point for the hands-on keyboard pass described here.

Related reading: UX Audit Checklist: 47 Things to Check Before Your Next Launch

Next Article