Use the website without a mouse: Test the entire user journey with a keyboard
A keyboard test of a real user task uncovers problems with navigation, focus, forms, contrast and screen readers that automated checks often miss.
Category: Web accessibility
Many accessibility tests focus on individual pages or isolated components. This can produce a tidy list of issues, but does not necessarily show whether a user can actually complete a task. A customer may need to find a service, compare alternatives, fill in a form and understand the confirmation. If one step fails, the entire user journey is effectively broken.
A review without a mouse is a simple and effective way to investigate this. The test highlights more than keyboard support. It also uncovers unclear wording, illogical order, weak focus indicators, forms that are difficult to understand, and content that works visually but poorly with a screen reader.
Choose a meaningful task
Do not start by clicking randomly around the homepage. Choose one specific task with a clear beginning and end. The task should be important to both the user and the organisation.
Relevant tasks may include:
- find the right service and submit an enquiry
- register for an event
- find contact information for a specific department
- add an item to the shopping cart and complete the purchase
- download a document after filtering a list
- log in and change a detail
Describe the task without revealing how to complete it. Write “Find the price of the service and request a quote” rather than “Open the menu, select Services and click the contact form”. This way, you test whether the interface actually guides the user forward.
Start with the keyboard only
Put the mouse aside. Use Tab to move forward, Shift and Tab to move backward, Enter to activate links and buttons, and the arrow keys where required by the component. Escape is often used to close menus, dialog boxes and other open elements.
Follow the entire task from start to finish. Note where you are unsure which element has focus, where the order seems illogical, and where a function cannot be used without a pointer. Do not limit your notes to purely technical errors. Friction and uncertainty are valuable information too.
Focus must remain visible throughout
A keyboard user must be able to see where the next action will take place on the page. The focus indicator should therefore be clearly visible on links, buttons, form fields, tabs and other interactive elements. A subtle colour change is often insufficient, especially when elements have different backgrounds.
Check the focus indicator on both light and dark surfaces. It must have sufficient contrast against the surrounding area and must not be obscured by graphics, borders or fixed-position elements. A clear outline combined with a visual change in the element itself often works better than either alone.
Also make sure that focus does not disappear behind a fixed header or consent panel. An element can technically have focus without the user being able to see it. The solution is still difficult to use in that case.
The order should follow the task
The focus order should match the visual and logical order. If the keyboard jumps from the main content to the sidebar, then to the footer and back to the form, the page becomes difficult to understand.
These problems often arise when elements are moved visually with CSS without the structure in the code following the same order. They can also be caused by positive tabindex values or hidden elements that can still receive focus.
Do not try to fix an illogical structure by carefully controlling every individual tab stop. Instead, start with a sensible content order in the code and use the default behaviour wherever possible.
Examine menus, dialogs and dynamic components
Standard links and buttons generally work well with a keyboard when they are built using the correct HTML elements. Custom menus, dropdowns, date pickers, carousels and dialog boxes require more consideration.
When a dialog box opens, focus should move into it. The user must be able to navigate between relevant options without landing on the content behind the dialog. When it closes, focus should normally return to the element that opened it.
Also test what happens when Escape is pressed, when the user navigates backwards, and when a component is opened again. A solution that works the first time may lose focus or lock the keyboard after repeated use.
Make the form part of the test
Forms should be tested as tasks, not as a collection of individual fields. Enter valid and invalid values, skip required fields and submit the form. Check whether the user understands what went wrong, where the error is and how to correct it.
Labels must be clear
Every field needs a visible and precise label. Placeholder text inside the field should not be the only explanation. It disappears when the user starts typing and may have poor contrast.
Instructions should appear before they are needed. If the password must meet specific requirements, those requirements should be available before submission. Do not wait to explain them until the user has made an error.
The error message must help the user move forward
“Invalid value” is rarely enough. A better message explains both the problem and the expected format, for example that the date must be entered as day, month and year.
After submission, the user should receive a clear summary of the errors. It should be easy to find the fields that need correcting, including with a keyboard and screen reader. Do not use only red to indicate errors. Combine colour with text, a symbol or another clear indicator.
Repeat the task with a screen reader
The keyboard test shows whether elements can be reached and used. A screen reader test shows whether the structure and information make sense without the visual presentation.
It is useful to start with the same user task. Listen to how headings, links, buttons and field names are read aloud. Check whether it is possible to understand the page structure and find your way around without listening to all the content in sequence.
Pay particular attention to:
- whether the page has a clear and logical heading structure
- whether link text makes sense without the surrounding text
- whether buttons have names that describe the action
- whether images with important content have suitable alternative text
- whether decorative images are skipped
- whether status messages and form errors are conveyed
- whether open and closed states are announced
A button with a magnifying glass may be visually obvious, but it must still have an understandable name. Similarly, multiple buttons should not be called “Read more” if screen reader users cannot tell what they refer to.
Check contrast in the right context
Contrast is not just about body text. Also check help text, menu items, field borders, error messages, icons, charts, focus indicators and buttons in different states.
Test components as they are actually used. A button may have good contrast in its normal state but become unreadable when focused or disabled. Text placed over an image may work in one crop and disappear in another.
Automated tools can measure many color combinations, but they do not always understand which background the text actually appears on, or whether color alone conveys meaning. Therefore, combine measurements with a visual assessment of the actual page.
Relate findings to WCAG without losing sight of the user journey
WCAG provides criteria that make accessibility possible to specify and evaluate. The criteria are useful when findings need to be described, prioritized and verified. However, they should not be the only structure in the report.
First record where in the task the problem occurs and what the consequence is. Then link the finding to the relevant requirement. An example could be: “The user cannot open the date picker with the keyboard and therefore cannot submit the order.” This wording makes both the problem and the business consequence clearer than a code alone.
A practical record should include:
- which task was tested
- the step where the problem occurred
- expected and actual behavior
- which users may be affected
- severity and consequence
- suggested fix
- how the fix will be retested
Fix the flow, not just individual details
When testing is complete, the findings should be grouped by root cause. Ten unclear buttons may be due to a lack of rules for button labels. Multiple focus problems may stem from a single dialog component used throughout the website. Errors in many forms may have the same origin in a shared field component.
This leads to more lasting improvements than fixing each occurrence manually. Update the design pattern, component and editorial guidelines at the same time. Then repeat the same task using the keyboard and a screen reader.
The goal is not merely for each element to pass an isolated check. The goal is for a person to understand the choices, navigate in the correct order, detect errors and complete the task without a mouse. When you test the entire user journey, accessibility becomes part of the service’s quality, rather than a separate check alongside the development work.
