Test the entire user journey without a mouse: A practical accessibility exercise

Category: Accessibility

A website can have good contrast, correct headings and clearly labelled form fields, yet still be difficult to use. Problems often arise in the transitions between pages: when the user opens the menu, filters content, selects an option, fills in a form and needs to understand the confirmation.

That is why accessibility should be tested as connected user journeys, not just as individual components. A useful exercise is to choose one important task and complete it without a mouse, with magnified content and with a screen reader. This gives the team a concrete picture of how design, content and technology work together.

Start with a task that matters

Do not begin the test on a random subpage. Choose a task that is important both to the user and to the organisation. This could be finding contact information, ordering a service, signing up for an event or submitting an enquiry.

Describe the task with a clear starting point and end point. One example could be:

Find the right service from the home page, read what it involves, fill in the contact form and confirm that the enquiry has been sent.

This wording makes it possible to assess whether the user actually reaches their goal. It also reveals obstacles that an isolated check of buttons, contrast or field labels can easily overlook.

Consider choosing three user journeys:

• A simple information task, such as finding opening hours or prices.
• A navigation task, such as finding the right service or product.
• An action task, such as submitting a form or completing an order.

Test on a computer first. Then repeat the most important parts on mobile, because order, zoom, menus and forms can behave differently on a narrow screen.

First review: Put the mouse aside

Keyboard navigation is a simple and effective introduction to accessibility. Put the mouse aside and use Tab to move forward, Shift and Tab to move backward, Enter to activate links and buttons, and the arrow keys where the component requires them.

Keep track of four questions:

• Can you see where the focus is? The active link, button or field must have a clear focus indicator.
• Is the order logical? Focus should follow the visual and meaningful order of the content.
• Can everything be operated? Menus, dropdown fields, dialog boxes, filters and forms must work without a mouse.
• Can you move forward? Focus must not become trapped in a component or disappear onto an invisible element.

A common problem is that the main menu can be opened with the keyboard but not closed. Another is that a dialog box opens visually while keyboard focus remains on the page behind it. The user may then end up navigating content that is no longer visible.

Also check whether there is a practical way to skip repeated navigation. Users should not have to go through the entire top menu on every new page.

Second review: Magnify and challenge the visual design

Good contrast is not just about ordinary body text. Also test help text, buttons, links, form borders, error messages, icons and text over images. Light grey text and subtle field borders may look neat in a design mock-up but become difficult to perceive in practical use.

Magnify the page significantly in the browser and perform the same task again. The content should still be readable and usable without text disappearing, buttons overlapping or users having to search for functions that have moved out of view.

Look especially for:

• Text cut off because the box has a fixed height.
• Buttons where the text wraps or disappears.
• Menus that cover content without being possible to close.
• Forms that require horizontal scrolling to understand fields and instructions.
• Information conveyed through colour alone.

For example, a red border around a field is not enough as an error message. Users need text explaining what is wrong and how it can be corrected. Similarly, active tabs, selected products or status messages should not be distinguished from the rest through colour alone.

Third review: Listen to the page with a screen reader

A screen reader test shows whether the page structure and labels make sense without the visual layer. It is often useful to start by listening through the headings. They should describe the content and form an understandable outline. If every section is called “Read more”, or important subheadings are merely visually formatted text, the page becomes difficult to navigate.

Then go through the links, buttons and form fields. Check that each element has a name explaining its function. A button announced only as “button” or a field announced only as “edit field” provides too little information.

Images that convey important content need a text alternative that serves the purpose. Decorative images should not create unnecessary noise. The goal is not to describe every pixel, but to convey the information the user needs in context.

Also pay attention to dynamic changes. If a product is added to the shopping cart, a search is updated or a form displays an error, the user must be told that something has happened. A visual message at the top of the page is of little help if the screen reader user is far down in the form and is not notified.

Fourth review: Provoke errors in the form

Do not test the form only with perfect information. Submit it with empty required fields, invalid formats and missing consent. This shows whether error handling actually helps the user get back on track.

An accessible form should have visible and programmatically associated labels, understandable requirements and precise error messages. Placeholder text inside the field should not be the only explanation, because it disappears when the user starts typing.

When the form is rejected, you should check:

• Whether the user receives a clear summary of what needs to be corrected.
• Whether each problem is explained next to the relevant field.
• Whether keyboard focus is moved or managed in a predictable way.
• Whether information that has already been entered is preserved.
• Whether the confirmation after submission is clear and understandable.

This test is not just about the form. It also checks whether headings, focus indicators, contrast, status messages and keyboard navigation work together.

Relate findings to WCAG without turning the test into a box-ticking exercise

WCAG provides criteria for keyboard use, contrast, structure, text alternatives, focus and error handling, among other things. The criteria are necessary when setting requirements and documenting quality, but they should not be the sole basis for the testing itself.

Record each finding with four details:

1. Which user journey and step the problem occurred in.
2. What the user attempted to do.
3. What actually happened.
4. Which WCAG area or internal requirement the finding relates to.

This gives the developer both a practical description of the error and a professional framework. “Poor accessibility in the menu” is difficult to fix. “The submenu opens with Enter, but keyboard focus does not move into the menu, and it cannot be closed with the keyboard” is specific and testable.

Prioritize based on impact, not on how easy the error is to fix

Accessibility findings should be prioritized based on what they prevent the user from doing. A missing focus indicator on a decorative link is not necessarily as serious as an order button that cannot be activated with the keyboard.

A simple prioritization could be:

• Blocking: The user cannot complete the task.
• Serious: The task can be completed, but requires workarounds, guesswork or assistance.
• Disruptive: The problem creates unnecessary friction or confusion.

Fix errors that recur in shared components first. One improvement to the menu, form component or button style can solve problems on many pages at once.

Make the exercise part of the delivery

The test should be conducted before launch and after major changes to navigation, design or functionality. Consider distributing the roles among the content manager, designer and developer. They identify different problems and can clarify solutions while the user journey is still fresh.

This exercise does not replace a full WCAG review, automated testing or testing with people who use assistive technologies daily. It nevertheless gives the team a practical method for identifying connected problems early.

The most important result is not a long list of non-conformities. It is that a key task can be completed using a keyboard, magnification and a screen reader, and that the user understands the content, choices, errors and confirmations along the way. Then accessibility becomes a quality of the entire user journey, rather than a layer added at the end.