The keyboard test: spend ten minutes trying your site without a mouse
Try one customer route with the keyboard. Record where focus goes, whether controls work and whether you can get out of an open menu.
Put the mouse aside and try requesting an appointment on your own website. You may find a button that cannot be reached or a menu that is difficult to leave. A brief test gives you specific observations to share with your site team.
Ten minutes is a suggested starting session, not an audit duration or a compliance test. Choose one important route and work carefully. If you cannot finish, record the barrier rather than guessing what a visitor would do next.
Know what you are looking for
W3C's Keyboard guidance explains the keyboard accessibility requirement in WCAG. No Keyboard Trap guidance addresses getting out of components using the keyboard. Focus Visible guidance explains visible keyboard focus. These are technical standards references, rather than an opinion about how convenient a site feels.
For this owner check, look for three things: can you reach the control, can you use it and can you move on? Keep those questions beside the task. You do not need to diagnose the code to report that a control could not be reached.
Prepare a safe task
Choose a route such as opening the contact page and reaching the submit button. If you plan to submit a test message, agree on the wording and destination first. Avoid a real purchase or booking that staff may mistake for a customer request.
Write down the starting page, browser and device. Close unrelated pop-ups so you know which page you are testing. Keep a second window or a notebook for observations. Do not change site settings halfway through the test without noting the change.
Move through the page
Try Tab to move through interactive controls and Shift+Tab to move backward. Use the visible focus indicator to follow your position. Record any place where the focus becomes impossible to see. A screenshot can help the developer identify the control you mean.
Try Enter on a link or button when appropriate. Some controls use other keys, such as arrows within a menu. If you do not know the expected behavior, write that down and ask a tester. Do not label a control broken solely because it uses an unfamiliar pattern.
Use the normal navigation to reach your chosen destination. Note whether you must pass through the same controls repeatedly. Keep the route specific enough that another person can repeat it from the same page.
Open and close the things that interrupt the task
If a menu, dialog or other panel appears, check whether you can use its controls and leave it. Try the documented close control and keyboard behavior. If you get stuck, note the exact step. W3C's No Keyboard Trap guidance explains why a keyboard trap is a barrier.
Do not spend the whole session trying to escape a single panel. Save the observation and ask the site team to investigate. Your record should say what opened, where focus went and which keys you tried. That is more useful than saying the site is awkward.
Try the form, including a mistake
Reach each field and check whether you can tell what it asks for. Enter safe test data. If you agreed to submit, try an incomplete entry first. Note whether the page explains the problem and gives you a way to correct it.
For an owner check, describe what you saw and heard rather than declaring that the form passes a standard. Keyboard operation is only part of accessibility. A later specialist review may assess screen-reader information and other barriers that this short session does not cover.
The DOJ web accessibility guidance names forms among examples of website accessibility issues. Keep the actual customer task at the center of your report. A working home page does not establish that the appointment form is usable.
Hand over a repeatable report
For each barrier, record the page address, intended task, steps and observed result. Add a screenshot if it makes the issue clearer. Assign someone to investigate and someone to repeat the test after the change. Keep the original observation beside the retest result.
If the entire route worked, record that too. Say which route, browser and device you used. Avoid expanding that finding into a statement that the whole website is accessible. A bounded result is easier to trust and repeat.
Use the next session for a different important route. Keep the list small enough that repairs can be followed through. The useful outcome is a growing record of checked customer tasks, rather than a one-time tick beside the word accessibility.
Access Heroes may earn a commission if you buy a tool we recommend. You pay the tool's maker directly, and we always tell you before you sign up. This article is general information, not legal or tax advice.
Sources
Found a keyboard barrier or want help choosing a test route? Book a free web accessibility check with TJ. He will look at your site with you and tell you what to fix first.
Comments