The Mouseless Challenge: The Easiest Keyboard Accessibility Test You’re Not Running

Keyboard accessibility means someone can use your website without a mouse. They should be able to move through the page, open menus, click buttons, fill out forms, close pop-ups, and understand where they are using only a keyboard.

The easiest way to test that? Unplug your mouse.

No, seriously. Put it in a drawer, disconnect it, shove it under a pile of cables. Whatever it takes.

Then open your own website and try to use it with the Tab, Enter, Space, and arrow keys. This is the Mouseless Challenge, and it will change how you see your work.

A quick website keyboard test can reveal problems that a screenshot, design review, or accessibility scan might not make obvious. In this blog, we’ll look at what breaks, why keyboard navigation is so important, and what to fix first.

Who Actually Uses Keyboard Navigation?

Before we get into the mechanics, let’s talk about who this affects.

Web accessibility can start to feel abstract when people treat it like a checklist instead of an actual person trying to use a website.

Keyboard users can include:

That last group is important, but it’s often the only group people think of. The reality is that keyboard navigation is far more common than most designers and developers realize, and it doesn’t require any assistive technology at all. It’s just Tab and Enter. Every browser supports it out of the box.

The CDC also reports that more than 1 in 4 adults in the United States have a disability.

And if you’re thinking, “My clients don’t have disabilities,” read my blog about why you need an accessible website anyway.

Ready To Try The Mouseless Challenge?

Good. Here’s how to run this simple website keyboard test. 

Use Keyboard Shortcuts to Navigate Each Page

For this test, you only need a few keyboard shortcuts: Tab to move forward, Shift + Tab to move backward, Enter or Space to activate buttons, and Escape to close most pop-ups or dialogs.

And at every step, ask yourself one thing: Can I tell where I am?

If the answer is no, your users probably can’t either.

What You’ll Find When You Test Keyboard Accessibility

Here’s what usually happens when most people run this test on a site they built, manage, or recently approved.

Keyboard Focus Jumps Somewhere Weird

You hit Tab and the first thing that gets highlighted is a link buried in the footer. Not your main navigation or your hero CTA. It’s never the first thing a visitor would logically need.

The visual hierarchy you carefully designed? The keyboard doesn’t know it exists unless you’ve explicitly told it to.

Interactive Elements Become a Black Hole

Custom menus, accordions, tabs, and dropdowns are some of the biggest keyboard navigation offenders.

They look fine. They animate nicely. Everyone likes the little arrow icon.

Then you try to use them without a mouse and suddenly you can’t open them, can’t reach the links inside them, or can’t get out once you’re in.

That’s one of the reasons custom controls need extra care. If something behaves like a button, it needs to actually work like one too.

You Fall Into Keyboard Traps

You open a modal window, and now you can’t get out of it without pressing Escape (if Escape even works).

Focus didn’t move to the modal when it opened, so you’re tabbing through the page content behind it. Or maybe focus did move to the modal, but when you close it, focus gets dropped to the top of the page instead of back to the button that opened it.

A person should be able to open a modal, move through it, close it, and land back where they started. If they have to guess what happened next, the interaction needs work.

The Focus Indicator Isn’t Visually Obvious

You’re pressing Tab and something is probably in focus somewhere on the page, but you can’t tell what it is because the focus indicator has been styled away.

That little outline around a focused element isn’t a browser quirk to be suppressed. It’s the keyboard equivalent of a cursor. It tells the user: you are here. Removing it because it clashes with your color palette removes your navigation system.

Luckily, you don’t have to use the browser default. You can style focus indicators to match your brand beautifully.

A colored border, a background color shift, an underline, a subtle shadow: all of these can be on-brand and visible. The WCAG 2.2 guidelines even give you specific criteria for what makes a focus indicator sufficient (contrast ratio, minimum area), so you’re not guessing.

What you can’t do, if you want an accessible site, is remove it entirely.
For more info about the legal requirements for accessible websites, read “Is My Website ADA Compliant? Let’s Clear That Up”

Tab Order Doesn’t Follow the Page

When you press Tab, the browser moves through focusable elements in the order they appear in the HTML.

That order might match what the page looks like.

Or it might not.

A common example is a sidebar that appears visually on the left but sits later in the page code. Someone using a keyboard may move through the main content first, then suddenly jump to the sidebar. Visually, that can feel completely backwards.

The same thing happens when pop-ups, menus, forms, and interactive cards are placed in strange source order.

You can control tab order with tabindex, but it should be used carefully.
Using tabindex values greater than 0 to manually reorder focus is considered an anti-pattern. It creates a custom tab order that’s hard to maintain and often makes things worse. The better fix is usually to reorder the HTML to match the visual layout, or reconsider the layout itself.

What you should use tabindex for:

The Reason Behind Many Keyboard Accessibility Issues

Here’s the thing experienced developers know and newer developers often learn the hard way: semantic HTML does a lot of accessibility work before you add anything fancy.

A real <button> element is keyboard focusable by default. It works with Enter and Space, and screen readers announce it as a button.

A <div> styled to look like a button gives you none of that on its own. To make it work properly, you have to add tabindex, keyboard event listeners, ARIA attributes, and then test the whole thing.

The same idea applies to links, form fields, selects, inputs, text areas, and details elements. Native interactive elements already come with expected keyboard behavior. Custom replacements can work well, but they need to be built carefully.

Before creating something custom, it’s worth asking: will this still work for someone who never touches a mouse?

The Fix May Be Smaller Than You Think

The good news? A lot of keyboard problems are fixable.

Some updates are fairly straightforward:

Small changes can remove a lot of friction.

Of course, some problems need more than a quick CSS update. Complex custom components, old themes, page builders, and third-party plugins can all introduce barriers. 

But even then, the Mouseless Challenge gives you a clear place to start.
One day without your mouse will surface more real problems than a full WCAG audit checklist ever will, because you’ll feel the friction, not just read about it.

That’s the point of the challenge. Experience it like a user who doesn’t have a choice.

Small fix. Big difference for the people who need it.

Ready to Catch the Stuff a Visual Review Misses?

Designers and developers already catch a lot. But keyboard issues, focus problems, and accessibility barriers can slip through when everyone is reviewing the site with a mouse.

The Mouseless Challenge is a good starting point. A full website accessibility audit gives you a clearer view: what’s working, what’s getting in the way, and what to fix first.

If you want to know where your site stands, my website accessibility services include a detailed review of the barriers affecting real users, along with clear recommendations for what to fix first. Book a complimentary consultation to get started.