Keyboard navigation: the accessibility test you can do yourself

If you are a SaaS founder, product manager, or e-commerce owner, you have probably asked: how do I test if my website is keyboard accessible? You do not need to hire a specialized agency or run expensive compliance software to find your most critical accessibility issues.

In fact, the most reliable accessibility audit you can perform is completely manual, costs zero dollars, and takes under ten minutes.

You simply unplug your mouse, disable your laptop trackpad, and attempt to use your website.

Because keyboard inaccessibility is the core trigger for digital ADA lawsuits, running this simple self-test is the most effective action you can take to identify security holes and protect your business from serial filers.

The manual keyboard test: the core controls

To run the test, you only need to use four keyboard commands:

• Tab: Moves your selection forward to the next link, button, or form field.
• Shift + Tab: Moves your selection backward to the previous link or button.
• Enter / Space: Activates the currently highlighted link or button (equivalent to a mouse click).
• Escape: Closes open menus, dropdowns, or modal popup windows.

With your mouse out of reach, open your homepage and press the Tab key. Observe how the page behaves. You are looking for three specific failure points that represent major WCAG violations.

Failure 1: The disappearing cursor (Missing focus indicators)

As you press the Tab key, you must see a visual indicator (typically a blue, black, or dotted outline box) surrounding the currently highlighted link or button. This is the focus state, and it acts as the visual cursor for keyboard users.

If you press Tab ten times and nothing changes visually on the screen, your site is broken. The browser is still moving the focus behind the scenes, but the user has no idea what link they are currently targeting.

This is almost always caused by a designer who disabled the browser's default focus ring in their CSS:

/* The code that breaks keyboard accessibility */
a:focus, button:focus {
  outline: none;
}

Designers do this because they think the default outline looks ugly during standard mouse clicks. But by deleting the outline without providing an alternative, they lock out every keyboard user.

• The Fix: Restore the outline, or design a custom focus state that matches your brand colors, ensuring it has high contrast against the background:

  a:focus-visible, button:focus-visible {
    outline: 3px solid #3b82f6;
    outline-offset: 2px;
  }
  

Failure 2: The mobile menu block

Many websites use custom JavaScript dropdown menus or hamburger menus on mobile and desktop viewports.

As you tab through your site:

1. Can you reach your main navigation links?
2. When you highlight a dropdown parent item, can you press Enter to reveal the sub-links?
3. If you open a mobile navigation panel, does the keyboard focus move into the open panel, or does it stay behind it, tabbing through the invisible links on the homepage?

If a keyboard user cannot open your navigation menu, they cannot visit any subpages. If they do open the menu but the tab focus remains stuck on the background page, they are trapped.

Failure 3: The checkout trap

A keyboard trap is one of the most frustrating barriers a user can encounter. It occurs when a user tabs into an element but cannot exit it.

This is highly common on:

• Cookie consent banners: The user tabs into the banner but cannot highlight the "Accept" or "Close" button. They are stuck in the banner forever.
• Cart drawers: An e-commerce user clicks "Add to Cart," and a cart slider opens from the side. The user tabs, but the focus remains on the background page. They cannot tab into the cart drawer to click "Checkout."
• Popup modals: A promo banner pops up offering a 10% discount. The user cannot tab to the "Close" button, and pressing the Escape key does not close the window. The modal blocks the entire screen.

To fix these traps, your developer must implement focus trapping. When a modal or drawer opens, JavaScript must intercept the Tab key and force the focus to loop inside the open element until the user explicitly closes it.

Why automated scanners miss these errors

You might wonder why you need to do this manually if you already run automated scanners like Google Lighthouse.

Automated tools are good at scanning static HTML, but they struggle with interactive JavaScript. A scanner can verify that your button has the correct button tag, but it cannot tell if a custom script prevents the Enter key from firing the button click event. It cannot feel if a modal creates a keyboard trap.

Only human testing can verify that your conversion flows work. If you find keyboard blocks or missing outlines during your test, a targeted front-end code optimization project can restore your focus states. Clean up your keyboard paths, test your checkout, and ensure every user can complete their purchase.