There is an accessibility test so simple that anyone can do it right now, without installing anything, without reading any guidelines, and without any technical knowledge. All you need is your keyboard.

Put your mouse in a drawer. Seriously. For the next ten minutes, try to use your website with nothing but your keyboard. You will discover problems you never knew existed — problems that affect far more people than you might think.

Why Keyboard Testing Matters

Most people assume keyboard accessibility is only relevant for blind users with screen readers. That assumption is wrong, and it causes businesses to overlook one of the most impactful accessibility improvements they can make.

Who Uses a Keyboard to Navigate the Web?

• People with motor disabilities. Conditions like cerebral palsy, muscular dystrophy, Parkinson’s disease, and repetitive strain injuries can make using a mouse painful, difficult, or impossible. Many of these users rely on keyboards, switch devices, or head-tracking tools — all of which depend on your website being keyboard-accessible.

• People who are blind. Screen readers are controlled primarily through keyboard commands. If your site does not work with a keyboard, it does not work with a screen reader.

• People with temporary injuries. A broken arm, a sprained wrist, or a hand surgery can force anyone into keyboard-only navigation for weeks or months.

• Power users. Many experienced internet users prefer keyboard shortcuts because they are faster than reaching for a mouse. Developers, writers, data analysts, and anyone who works at a computer all day often navigate with Tab, Enter, and shortcuts out of habit.

• People using assistive technology. Voice control software (like Dragon NaturallySpeaking), switch devices, and sip-and-puff devices all translate user input into keyboard commands. If your site works with a keyboard, it almost certainly works with these tools.

The bottom line: keyboard accessibility is not a niche concern. It is foundational. A website that fails keyboard testing fails a wide range of users.

The Keys You Need to Know

Before you start testing, here is your complete toolkit. You only need six keys.

Tab

The Tab key moves focus forward through interactive elements on the page — links, buttons, form fields, dropdown menus. Each time you press Tab, the focus should move to the next interactive element in a logical order.

Shift + Tab

Pressing Shift and Tab together moves focus backward. This is the “undo” for Tab. If you accidentally skip past something, use Shift+Tab to go back.

Enter

The Enter key activates the currently focused element. If a link is focused, Enter follows the link. If a button is focused, Enter clicks the button. If a form submit button is focused, Enter submits the form.

Space

The Space bar activates buttons (same as Enter for buttons), toggles checkboxes, and opens dropdown selects. Some interactive elements respond to Space but not Enter, or vice versa, so try both if something does not seem to work.

Arrow Keys

The up, down, left, and right arrow keys navigate within components. Inside a dropdown menu, arrow keys move between options. Inside a group of radio buttons, arrow keys switch between choices. Inside a tab panel, arrow keys switch between tabs.

Escape

The Escape key closes things — popups, modal dialogs, dropdown menus, tooltips. After pressing Escape, focus should return to the element that triggered the popup in the first place.

That is it. Six keys (or key combinations) cover virtually everything you need for keyboard testing.

How to Test: A Step-by-Step Walkthrough

Open your website in a browser. Click somewhere on the page (the address bar is fine) to make sure the browser window is active. Now put your mouse aside and follow these steps.

Step 1: Tab Through the Entire Page

Press Tab repeatedly from the top of the page to the bottom. Do it slowly enough to observe what happens with each press.

What you are looking for:

• Can you see where the focus is? Every time you press Tab, a visible indicator (usually an outline or highlight around the element) should appear. This is called a “focus indicator” or “focus ring.” If you press Tab and cannot tell where the focus moved, that is a critical failure. Keyboard users are essentially navigating blind without a visible focus indicator.

• Does focus move in a logical order? The focus should generally follow the visual layout of the page — top to bottom, left to right (for left-to-right languages). The navigation should come before the main content. The main content should come before the sidebar. The sidebar should come before the footer. If focus jumps to the footer before you have gone through the header, the tab order is broken.

• Can you reach every interactive element? Every link, button, form field, dropdown, and clickable item should be reachable by Tab. If you see a button on the page but Tab skips right over it, that button is inaccessible to keyboard users.

Take notes on anything that feels wrong. You do not need to know the technical cause yet — just write down “I could not Tab to the search icon” or “the focus jumped from the header to the footer.”

Step 2: Test Your Navigation Menu

Tab to your main navigation menu. This is where many websites fall apart.

What to test:

• Can you reach every menu item with Tab?
• If your menu has dropdowns, can you open them? Try pressing Enter, Space, or the Down Arrow on a parent menu item.
• Once a dropdown is open, can you move through the items with Arrow Keys or Tab?
• Can you close the dropdown with Escape?
• After closing the dropdown, does focus return to the parent menu item?

Navigation menus are one of the most common sources of keyboard accessibility failures. Custom mega menus, animated dropdowns, and hamburger menus on mobile are frequent problem areas.

Step 3: Test Your Forms

Tab to a form on your site — a contact form, a sign-up form, a search box, anything. Forms are where keyboard users interact the most.

What to test:

• Can you Tab into every form field (text inputs, dropdowns, checkboxes, radio buttons)?
• Can you type in text fields?
• Can you open dropdowns with Space or Enter and select an option with Arrow Keys?
• Can you check and uncheck checkboxes with Space?
• Can you switch between radio buttons with Arrow Keys?
• Can you submit the form with Enter?
• If there are error messages, can you reach them with Tab?
• If there is a date picker, calendar widget, or custom component, can you operate it entirely with a keyboard?

Custom form widgets (date pickers, color selectors, multi-select dropdowns) are especially prone to keyboard failures because they often rely on mouse-specific interactions.

Step 4: Test Popups and Modals

If your site has popups, modal dialogs, cookie consent banners, or chat widgets, test them.

What to test:

• When the popup appears, does focus move into it automatically? (It should. If it does not, keyboard users are stuck behind the popup and cannot interact with it.)
• Can you Tab through the content and buttons inside the popup?
• Can you close it with Escape or by Tabbing to a close button and pressing Enter?
• After closing, does focus return to where you were before the popup opened?
• While the popup is open, can you Tab past it into the page content behind it? (You should not be able to. Focus should be “trapped” inside the popup until it is dismissed. This is the one situation where trapping focus is correct.)

Step 5: Test Interactive Content

If your site has carousels, accordions, tabs, video players, image galleries, or sliders, test each one.

What to test:

• Can you reach the component with Tab?
• Can you operate it with keyboard keys? (Arrow keys for carousels and tabs, Enter or Space for accordions)
• Can you pause an auto-playing carousel?
• Can you play and pause videos?
• Can you adjust a slider value?

Interactive widgets that only respond to mouse clicks or swipe gestures are a major barrier for keyboard users.

What Problems Look Like (and How Serious They Are)

Critical: Keyboard Traps

A keyboard trap is any place on the page where you can Tab in but cannot Tab out. You press Tab repeatedly and the focus stays stuck on the same element or cycles within a small group of elements with no way to escape.

This is the most severe keyboard accessibility failure. It literally prevents users from using the rest of your website. Common sources include poorly built modals, embedded maps (Google Maps iframes are a frequent offender), embedded videos, and third-party chat widgets.

How to fix: The simplest fix is to ensure that the Escape key closes any component that captures focus, and that Tab eventually moves past embedded content. For third-party embeds like maps, make sure the iframe has a tabindex="-1" attribute or that there is a “skip” mechanism to bypass it. You will likely need a developer for this fix.

Critical: No Visible Focus Indicator

If you Tab through your page and cannot see any visual indication of where the focus is, keyboard users cannot navigate your site. This happens when developers intentionally remove the focus outline because they think it looks ugly (it does when triggered by mouse clicks, but removing it entirely is destructive).

How to fix: The focus indicator should be visible and clear. A 2-pixel outline in a contrasting color is the standard approach. If your site has removed focus styles, a developer can add them back with a few lines of CSS. Modern CSS has a feature called :focus-visible that shows the focus ring only for keyboard users, not mouse users — this is the ideal solution that satisfies both designers and accessibility.

Serious: Unreachable Interactive Elements

If a button, link, or form field cannot be reached with Tab, it is invisible to keyboard users. This usually happens when interactive functionality is built with div or span elements (which are not keyboard-accessible by default) instead of proper button or a elements.

How to fix: The element needs to be changed to a proper interactive HTML element, or it needs keyboard attributes added. This requires a developer, but the fix is usually straightforward.

Serious: Broken Tab Order

If the focus jumps around the page in an illogical order — footer to header to sidebar to main content — users get disoriented. This usually happens when developers use the tabindex attribute incorrectly or when the visual layout does not match the underlying code order.

How to fix: In most cases, removing tabindex values and ensuring the HTML source order matches the visual layout resolves the issue. Share your observations with your developer: “When I Tab from the search bar, focus jumps to the footer instead of the main content.”

Moderate: Missing Skip Links

When you Tab from the very beginning of the page, you often have to Tab through the entire navigation menu before reaching the main content. On a site with 20 navigation links, that means pressing Tab 20 times on every single page. This is exhausting for keyboard users.

A “skip to main content” link solves this. It is the very first focusable element on the page. When you press Tab once, you see a link that says “Skip to main content.” Press Enter, and focus jumps directly to the main content area.

How to fix: Adding a skip link is a straightforward code change that most developers can implement in under an hour. Many modern themes and frameworks include one by default.

Moderate: Non-functional Enter or Space

If you Tab to a button and pressing Enter or Space does nothing, the element looks interactive but is not properly coded. This often happens with buttons that rely on mouse click handlers but do not have corresponding keyboard event handlers.

How to fix: The developer needs to add keyboard event support to the element, or better yet, convert it to a proper HTML button element that handles keyboard events natively.

How to Report What You Find

After testing, you will have a list of observations. Here is how to organize them so your developer or agency can act on them efficiently.

For Each Issue, Record:

1. Where it happens — the specific page URL and section of the page
2. What you did — “I pressed Tab from the search bar” or “I pressed Escape on the popup”
3. What happened — “Nothing was visible” or “Focus jumped to the footer”
4. What you expected — “I expected to see a highlight around the next menu item”

This format gives developers everything they need to reproduce and fix the problem without guessing.

Prioritize Like This:

1. Fix immediately: Keyboard traps and missing focus indicators (users literally cannot use the site)
2. Fix soon: Unreachable buttons and form fields (users cannot complete key tasks)
3. Fix when possible: Tab order issues and missing skip links (users can complete tasks but with difficulty)

Making Keyboard Testing a Habit

The best time to test keyboard navigation is:

• Before launching a new page or redesign. Catch problems before they affect real users.
• After adding new features or plugins. Third-party widgets (chat tools, booking calendars, pop-up forms) are the most common source of new keyboard issues.
• Monthly, on your most important pages. A quick five-minute Tab-through of your homepage, product pages, and checkout flow keeps things in check.

You do not need to be an expert. You just need to put down the mouse and pay attention to what happens. If something feels broken or confusing to you, it is broken and confusing to every keyboard user who visits your site.

The keyboard test is the single most valuable accessibility check you can perform, and it costs nothing. Start with your homepage. Tab through it. Write down what you find. Share it with whoever maintains your site. That one action puts you ahead of the vast majority of businesses on the web.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.