Websites & support / Checklist
Can a customer use your website without a mouse?
Put the mouse aside and try opening the service menu on your website. Follow a service link, then find the route for asking a question. That short journey can reveal a problem that a visual review misses.
Some customers rely on keyboard controls or technology that uses keyboard interaction. I want the ordinary jobs on a business website to work for them too.
Choose one task with a clear finish
For an initial check, pick something specific: finding a service and reaching its enquiry form, for example. Write down the page where the customer starts and the point they need to reach.
W3C’s keyboard criterion concerns operating functionality through a keyboard interface, with a limited exception for underlying path-dependent input such as freehand drawing. An ordinary service menu should not depend on somebody using a mouse pointer.
Watch where the keyboard focus goes
Use Tab to move forward through controls and Shift+Tab to move back. Look for a visible indication of the current item. You should be able to tell which link or button will respond before activating it.
Check the route through the page as well as the appearance of that indicator. Notice if the order jumps somewhere unexpected or a sticky panel hides the control you have reached.
If you lose track, record the page and the last item you could identify. That gives the person fixing the site a more useful starting point than a report that the menu feels awkward.
Source: WAI: easy accessibility checks
Open the menu and get out again
Try opening a menu, reaching an item and closing it. Use the appropriate keyboard controls for the element; links, buttons and list controls do not all behave in exactly the same way.
Check that you can continue through the page afterwards. A control that accepts focus but leaves somebody unable to move away can stop the whole task. WAI’s initial checks call out this kind of keyboard trap.
Source: W3C: understanding keyboard operation; WAI: easy accessibility checks
Continue into the useful part of the form
In an authorised test copy, use fictional details to check that fields have useful labels and can be reached. Where the task involves a choice, check that its options can be operated from the keyboard too.
If the test includes an ordinary required-field error, check that somebody can find the problem, correct it and carry on. Keep the test isolated from real enquiries, orders and customer messages.
Record the task that needs attention
Keep a short record of what you tried, the browser and the step that failed. After a correction, repeat the same route so you can compare the result.
WAI is clear that these early checks cover only some accessibility issues. A page can pass them and still have significant barriers. Use the findings to plan the next review, including other assistive-technology and user checks appropriate to the website.
Bring one customer journey when we discuss your site. We can work through the steps and decide what needs a closer assessment.
Source: WAI: easy accessibility checks
Sources
Checked on 23 October 2026.
- W3C: understanding keyboard operation
Keyboard operation of functionality, its path-dependent-input exception and the role of suitable control behaviour.
- WAI: easy accessibility checks
Initial checks for focus, keyboard order, traps and forms, with an explicit warning that they are not a comprehensive accessibility evaluation.
