How Can I Test My Website Without Using a Mouse?

A keyboard-only test checks whether someone can complete important website tasks without using a mouse. It can expose barriers that are easy to miss when a designer clicks directly on every control.

It is a useful first review, not a complete accessibility audit. Screen-reader behaviour, visual presentation and other requirements need additional evaluation.

Choose one meaningful customer task

Start with a realistic task such as finding a service and sending a test enquiry. Use a harmless test submission and make sure the receiving team knows it is not a real lead.

Include the homepage, navigation, relevant service page and form. Testing only the first few links misses problems in menus, dialogs and embedded booking tools.

The website accessibility guide explains why access must cover the whole service rather than a single page.

Put the mouse aside

Use Tab to move between many standard interactive controls and Shift+Tab to move backwards. Enter commonly follows links or activates buttons; Space commonly activates buttons and checkboxes. Some components have additional expected keys.

W3C’s keyboard guidance explains the requirement for keyboard operation, with limited exceptions for input that inherently depends on a movement path.

Do not assume that every visual object should receive keyboard focus. Ordinary paragraphs are read differently from interactive controls.

Watch where focus goes

There should be a visible indication of the current control. Follow the sequence through the page and check whether it makes sense.

If focus disappears behind a sticky header or jumps to an unexpected area, record the exact step. A page may technically receive keystrokes while leaving the user unable to tell where they are.

Try moving backwards as well as forwards. A route that works only in one direction can still trap someone during correction.

Exercise the awkward components

Open and close the mobile menu, any disclosure panels and an important dialog. Check whether you can reach the controls, understand the current state and return to the surrounding page.

For example, a fictional appointment site may let someone open a booking dialog but provide a close control that cannot be reached. The customer has entered the journey but cannot leave it using the same input method.

Do not repair this by adding arbitrary positive tab-order numbers throughout the page. Ask the developer to address the underlying structure and component behaviour.

Record barriers in task order

Step	Expected action	Observation
Navigation	Reach and open service menu	Record whether focus is visible
Service page	Follow enquiry link	Record destination and order
Form	Enter and correct details	Record reachable fields and errors
Dialog	Close and continue	Record where focus returns

Fill this with observed results, not assumed passes. Include browser, device and the exact reproduction steps.

The form-error guide covers correction behaviour in more detail.

Retest after a focused change

Prioritise blockers that prevent completion, then confusing or inefficient interactions. Give the developer the smallest reliable reproduction sequence.

Repeat the original task after the repair and include another page using the same component. A shared menu fix should be checked in more than one context.

Our usability testing guide helps extend this to observation with real users, including disabled participants where appropriate.

Keep the result modest and accurate: “The selected tasks passed this keyboard check” is defensible. “The website is fully accessible” requires much broader evidence.

Thinking about your own rebuild?

Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.

Tell us about your project↗

• Accessibility
• Small business