Keyboard Navigation Testing Guide: How to Test Website Accessibility

Here's a simple accessibility test: unplug your mouse and try to use your website.

That's it. That's the whole test. And most sites fail it immediately.

Who Actually Uses Keyboards to Navigate?

More people than you'd think:

If they can't tab through your site, they can't use it. Simple as that.

The Basic Keys

Quick primer if you've never done this:

Try It Right Now

Seriously, do this:

1. Put your mouse in a drawer

2. Go to your site's homepage

3. Hit Tab repeatedly until you've gone through everything

4. Try to complete a key task (sign up, buy something, whatever)

Pay attention to:

Can you see where you are? There should be a visible outline or highlight on whatever's focused. If focus just disappears into the void, that's a problem.

Does the order make sense? Focus should generally flow left-to-right, top-to-bottom—following how you'd read the page.

Can you reach everything? Every button, every link, every form field should be reachable.

Can you escape? Open a modal. Can you close it with Escape? Open a dropdown. Can you close it? You'd be surprised how often people get trapped.

The Stuff That Usually Breaks

Invisible Focus

Designers love to remove focus outlines because they look "ugly." Don't.

/* This ruins everything */
*:focus { outline: none; }

If the default outline bugs you, style it differently. Just don't delete it:

*:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

The :focus-visible selector only shows the outline for keyboard users, not mouse clicks. Best of both worlds.

Clickable Divs

Developers do this all the time:

<div onclick="doThing()">Click me</div>

You can't tab to a div. Keyboard users will never reach it.

Just use a button:

<button onclick="doThing()">Click me</button>

If you absolutely must use a div (you probably don't), you need to add a bunch of stuff:

<div role="button" tabindex="0" onclick="doThing()" onkeydown="if(event.key==='Enter')doThing()">
  Click me
</div>

See how annoying that is? Just use a button.

Keyboard Traps

A trap is when you can tab *into* something but can't tab *out*. Modals are notorious for this.

When a modal opens, focus should move into it. When it closes, focus should go back to whatever opened it. And while it's open, Tab should cycle through just the modal's contents—not escape into the page behind it.

Here's the basic idea:

modal.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    closeModal();
    triggerButton.focus(); // Return focus to what opened it
  }

  if (e.key === 'Tab') {
    // Keep focus cycling within modal
    // (implementation depends on your setup)
  }
});

No Skip Link

Imagine tabbing through a site with 50 navigation links. On *every single page*. Before you can reach the actual content.

Skip links fix this:

<a href="#main" class="skip-link">Skip to content</a>

<!-- later -->
<main id="main">...</main>

Hide it until focused:

.skip-link {
  position: absolute;
  top: -100px;
}
.skip-link:focus {
  top: 10px;
}

First thing keyboard users see. Lets them jump straight to the good stuff.

Menus That Only Work with Hover

If your dropdown menu opens on hover, it doesn't work for keyboards. At all.

The menu button needs to toggle on Enter/Space, and arrow keys should move through menu items. It's more code, but there's no way around it.

Make It Automatic

Every time you add something interactive, tab to it. Takes 5 seconds. Catches problems before they ship.

For everything else, scan with ClearA11y to find focus issues, missing labels, and other keyboard blockers automatically.