Can customers use your website without a mouse? A simple keyboard check

Could a visitor reach your services, open your menu and send an enquiry without using a mouse? A short keyboard check can reveal places where that journey stops. You do not need to edit any code to make a useful first list of problems.

Keyboard access matters because some people cannot use a mouse, while others use tools that send keyboard commands. The W3C guidance on keyboard access explains why website functions need a keyboard equivalent. Start with one real customer task, such as finding a service and reaching its enquiry form.

1. Choose a small route to test

Open your homepage in a desktop browser. Write down the browser name, the date and the task you want to complete. Put the mouse aside once the page is ready. Include the main menu, a service page and the contact form in your route.

Use Tab to move forwards between interactive items and Shift + Tab to move backwards. Enter normally follows a link; buttons generally respond to Enter or Space. Some controls, such as groups of options, use arrow keys. If your browser skips links, check its keyboard-navigation settings before recording a website fault. W3C’s Easy Checks guidance includes browser setup notes.

2. Keep track of your position

As you move, look for a visible outline or other clear change on the current link, button or field. This is called keyboard focus. You should be able to tell where the next keyboard action will apply.

The W3C explanation of visible focus describes why this indicator is needed. If it disappears, record the last item you could see and how many further Tab presses you made. A screenshot can help your developer find the problem.

Watch for focus moving behind a banner or to an unexpected part of the page. If a “Skip to content” link appears near the start, try it: it should let you bypass repeated navigation and move towards the main content.

3. Open and leave menus and pop-ups

Try the menu, any expandable answers and any pop-up that interrupts your chosen route. Can you reach the controls, open them, use their contents and close them using the keyboard?

A dialogue may intentionally keep focus inside while it is open. The important question is whether you can close it and continue. Test its close button and, where supported, Escape. If you become stuck and need the mouse to escape, note the exact sequence. W3C’s guidance on keyboard traps explains the need for a keyboard way out.

4. Follow the enquiry route

Move through the contact form in the order a customer would use it. Can you reach each field, select any required options and find the send button? Check that the labels make it clear what to enter.

If you submit a test, use your own details and clearly label the message as a website test. Avoid making a real booking or payment just to check navigation. For a fuller check of delivery and confirmation messages, follow our guide to testing a contact form from start to finish.

5. Turn the findings into a clear repair list

For each problem, record the page address, the control, the keys you pressed, what you expected and what happened. For example: “On the services page, Tab reaches the menu button, but Enter and Space do not open the menu.” This gives your developer a specific fault to reproduce.

Start with problems that stop the customer task entirely. After a repair, repeat the same route and check that you can still move forwards and backwards.

This is a useful first review, not a complete accessibility assessment. W3C’s Easy Checks guidance makes clear that a page can pass simple checks and still have significant barriers. Keep your notes for a wider review, especially when a new menu, form or booking tool is added.

Want to discuss a difficult step on your website? Contact Hobbit Web Design with the page address and the task you were trying to complete.