A 5-Minute Keyboard Accessibility Test for Your Online Store
Short answer: Put your mouse aside and use Tab, Shift+Tab, Enter, Space, arrow keys, and Escape to move through your store from the homepage to checkout. If you can't reach, see, or operate something, or you get stuck, that is a keyboard accessibility failure worth fixing.
Many people browse without a mouse: people with motor disabilities, people who use screen readers, and anyone with a broken trigger finger or a sore wrist. If your store only works with a mouse, those customers cannot buy from you. Keyboard problems are also among the easiest accessibility failures to find yourself.
This test takes about five minutes and needs no tools. It is a quick check, not a full audit, and passing it does not mean your site is compliant with anything. It is a practical way to find the most obvious barriers before they cost you sales or turn up in a demand letter.
Before you start
Open your store in a regular browser window. Then:
- Put your mouse or trackpad out of reach so you aren't tempted to click.
- Start on your homepage and reload it so focus begins at the top of the page.
- Keep a note open to jot down the page and the step where anything goes wrong.
These are the keys you will use:
| Key | What it does |
|---|---|
| Tab | Moves focus forward to the next link, button, or field |
| Shift + Tab | Moves focus backward |
| Enter | Activates links and buttons |
| Space | Activates buttons, toggles checkboxes, opens select menus in some browsers |
| Arrow keys | Move within menus, radio groups, tabs, and sliders |
| Escape | Closes pop-ups, dialogs, and open menus |
On a Mac, Safari and Firefox may need a setting turned on before Tab reaches every link. In Safari, enable "Press Tab to highlight each item on a webpage" in Advanced settings. Chrome works without changes.
Step 1: Press Tab once and look for focus
Press Tab and watch the screen. You should see a clear visible indicator, usually an outline or highlight, on the first interactive element.
What failure looks like: You press Tab several times and can't tell where you are. The outline is missing, is the same color as the background, or is so faint you lose it.
What to tell your developer: "Keyboard focus is not visible on [element]. Please restore a clear focus indicator." A frequent cause is a stylesheet rule that removes the outline for looks:
/* Problem: removes the focus indicator for everyone */
button:focus { outline: none; }
/* Better: keep a clear, visible indicator */
button:focus-visible { outline: 3px solid #1a56db; outline-offset: 2px; }This relates to WCAG 2.4.7 Focus Visible.
Step 2: Look for a skip link
On the very first Tab press, many well-built sites show a "Skip to main content" link. Pressing Enter on it jumps past the header and menu straight to the page content.
What failure looks like: There is no skip link, so a keyboard user must tab through every logo, menu item, search box, and cart icon on every single page before reaching the products.
What to tell your developer: "Please add a skip link as the first focusable element that moves focus to the main content." See WCAG 2.4.1 Bypass Blocks. Pages with only a few links in the header may meet the intent in other ways, such as landmarks, so treat a missing skip link as a flag to investigate rather than an automatic failure.
Step 3: Tab through the header and main menu
Keep pressing Tab through the logo, navigation, search, account, and cart links. Then try opening a dropdown or mega-menu using Enter, Space, or the arrow keys.
What failure looks like:
- The dropdown opens only on mouse hover, so keyboard users never see the sub-items.
- Focus skips over menu items entirely.
- A menu opens but you can't close it with Escape and it covers the page.
- Focus order jumps around illogically, such as from the logo to the footer and back.
What to tell your developer: "The main navigation is not operable by keyboard. Submenus need to open on Enter, Space, or arrow keys, close on Escape, and return focus sensibly." This is covered by WCAG 2.1.1 Keyboard.
Step 4: Use search and filters
Tab to the search box, type a term, and press Enter. On the results or category page, try the filters and the sort control.
What failure looks like: The search icon is a clickable image that can't be reached with Tab. Filters are built from clickable elements that don't respond to Enter or Space. A "price range" slider can't be moved with the arrow keys.
What to tell your developer: "Custom controls need to be real buttons, inputs, or links, or need equivalent keyboard behavior and accessible names." The underlying criterion is WCAG 4.1.2 Name, Role, Value. Unlabeled fields are a separate but related problem; see WCAG 3.3.2 Labels or Instructions.
Step 5: Open a product page and pick options
Tab into a product, then try selecting a size, color, and quantity. Use Tab to reach each choice and the arrow keys within groups of options.
What failure looks like:
- Color swatches or size boxes can be seen but never receive focus.
- You can pick an option but nothing shows which one is selected.
- The image gallery can only be changed by clicking tiny dots.
- The "Add to cart" control is reachable, but pressing Enter does nothing.
What to tell your developer: "Variant selectors and the image gallery are not keyboard accessible. Please use native radio buttons or buttons, and expose the selected state." Product image descriptions are a separate topic covered in alt text for product images.
Step 6: Add to cart and handle pop-ups
Press Enter on "Add to cart." Many stores respond with a slide-out cart or a pop-up dialog.
What failure looks like: Focus stays behind the dialog on the page underneath, so the next Tab press goes to products you can no longer see. Or the opposite: focus gets stuck inside the dialog with no way to close it. Pressing Escape does nothing.
What to tell your developer: "When the cart drawer or dialog opens, focus should move into it and stay inside until it closes. Escape should close it, and focus should return to the button that opened it."
This kind of "keyboard trap" is a serious problem because the person cannot continue at all. It is another case of WCAG 2.1.1 Keyboard.
Step 7: Go through checkout
Proceed to the cart page, then through checkout. Fill in every field using only the keyboard: name, address, shipping method, and payment.
What failure looks like:
- A dropdown (state, country) can't be opened or changed.
- Required fields aren't announced as required, or error messages appear only as red text you can't reach.
- The payment form, often embedded from a third party, can't be tabbed into.
- The final "Place order" button is not reachable.
What to tell your developer: "Checkout cannot be completed by keyboard alone. Here is the exact step where it fails." If the failure is inside an embedded payment provider, tell your developer too, because they may be able to switch to an accessible option or contact the provider.
Step 8: Tab backward and check the footer
Use Shift + Tab to move backward through a page. Focus should retrace the order in reverse. Then tab to the footer and check that its links are reachable and that nothing, such as a cookie banner or chat widget, is blocking them.
What failure looks like: A cookie banner or chat bubble captures focus and can't be dismissed, or it sits on top of controls that are now unreachable.
What to do with your results
Write down each failure with three details: the page, the step, and what happened. Developers can fix issues much faster from "On the product page, the size swatches can't be reached with Tab" than from "the site isn't keyboard accessible."
If you are responding to a demand letter, a dated record of what you tested and when is useful to show you took the issue seriously. See dated accessibility audit record and how to read an ADA website demand letter. A manual keyboard test is a good start, but a full review also covers contrast, headings, forms, and more; the WCAG 2.1 AA checklist lays out what else to check. Be cautious about quick fixes sold as a one-click solution; see accessibility overlays and lawsuits.
To go beyond a manual spot check, you can run a free scan of your store to catch the issues a keyboard test can't.
This guide is general information, not legal advice. For questions about your legal exposure, talk to an attorney.
Frequently asked questions
Does passing this keyboard test mean my store is accessible?
No. It checks only one part of accessibility, how well your site works without a mouse. A store can pass every step here and still have problems with color contrast, missing image descriptions, unlabeled form fields, or video captions.
Do I need special software to run this test?
No. You only need a browser and a keyboard. On a Mac, you may need to adjust a Safari or Firefox setting so the Tab key reaches all links and buttons, as described above.
Can an accessibility overlay or plugin fix keyboard problems for me?
Usually not fully. Keyboard problems come from how your pages and components are built, so they generally need to be fixed in the code or theme. Opinions and legal outcomes around overlays vary, so read the overlay guide on this site before relying on one.
What is a keyboard trap?
A keyboard trap happens when focus enters a part of the page, such as a pop-up or embedded widget, and the user cannot leave it using the keyboard. It is one of the most severe keyboard failures because it can stop a customer from finishing a purchase.
How often should I repeat this test?
Repeat it whenever you change your theme, add a plugin, redesign checkout, or install a new widget. Even without changes, a periodic check is sensible, since updates to apps and third-party tools can introduce new problems.
Related
- WCAG 2.1.1 Keyboard
- WCAG 2.4.7 Focus Visible
- WCAG 2.1 AA checklist for business websites
- WCAG 4.1.2 Name, Role, Value
Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.