Test the most important user journey without a mouse – and find the barriers that stop the customer

A website can pass many automated accessibility tests and still be difficult to use. The problem is often that testing is done page by page, while users need to complete a connected task: find the right service, understand the terms, fill out a form and receive confirmation.

That is why accessibility work should also be based on user journeys. Choose one important task and complete it using a keyboard, screen reader and visual inspection. This will reveal barriers that isolated component tests can easily overlook.

The method is particularly well suited to contact forms, bookings, applications, registrations and purchasing journeys. It can be used during development, before publication and as part of regular quality assurance.

Start with one task that matters

Do not begin by testing the entire website. Choose a task that is important to both the user and the organisation. This could be booking a site inspection, signing up for a course or requesting a quote.

Describe the task without explaining how it should be completed. A simple test task could be:

Find the service relating to bathroom renovation, find out what the company offers, and submit a request for a site inspection.

Note which pages, menus, buttons, dialog boxes and form fields the user must go through. Also include what happens after submission. A confirmation is part of the user journey, not an add-on.

Then define a few acceptance criteria:

• The entire task should be possible to complete without a mouse.
• It should be clear where the keyboard focus is located.
• Content, controls and error messages should be understandable with a screen reader.
• Text and important interface elements should have sufficient contrast.
• The form should explain what is required, what went wrong and how to fix the error.

WCAG provides the criteria you need to meet. The user journey shows whether the solution actually works as a whole in practice.

First review: Do everything with the keyboard

Put the mouse aside. Use Tab to move forward, Shift and Tab to move back, Enter or Space to activate controls, and the arrow keys where the component requires them.

Follow the journey from start to finish. Do not test only whether it is possible to reach a button. Consider whether the order is understandable, whether the focus is visible and whether the component behaves as expected.

Look for these problems

• Invisible focus: You do not know which link, button or field is active.
• Illogical order: The focus jumps to sidebars, footers or hidden elements before continuing through the main content.
• Keyboard trap: The user can enter a menu or dialog box but cannot exit it.
• Skipped elements: Clickable cards, custom drop-down lists or icons can only be used with a mouse.
• Unexpected change: A selection submits the form, opens a new view or moves the focus without clear warning.

A common mistake is removing the browser’s default focus indicator because it does not fit the design. If the indicator is replaced, the new one must be at least as clear. Focus should be easy to see on both light and dark surfaces and in all interactive states.

Also test menus and dialog boxes. When a dialog opens, the focus should move into it. When it closes, the focus should normally return to the element that opened it. This allows the user to continue without having to find their way back from scratch.

Second review: Listen to the journey with a screen reader

A screen reader conveys more than the text on the screen. It conveys structure, roles, names and states. A visually clear button can therefore become incomprehensible if it is read aloud only as “button” or “read more”.

Start by listening to the page in the usual reading order. Then navigate by headings, links and form fields. The goal is not to master every command, but to discover whether the content has an understandable structure.

Check what the user actually hears

• Does the page title tell the user where they have arrived?
• Do the headings form a meaningful table of contents?
• Do links and buttons have names that make sense without the surrounding text?
• Do images have alternative text when the subject conveys important information?
• Are decorative images omitted from the reading?
• Are open menus, selected tabs and expanded sections conveyed with the correct state?
• Are confirmations and error messages read aloud when they appear?

Prefer standard HTML elements whenever there is an element suited to the task. A real button has built-in keyboard support and a recognised role. A clickable text area that imitates a button requires more code and creates more opportunities for errors.

Be careful about using hidden helper text as a fix for unclear content. What is unclear to a screen reader user may also be unclear to others. A button labelled “Send request” is generally better than “Send”, both visually and when read aloud.

Third review: Check contrast and visual cues

Contrast applies to more than body text. It affects links, buttons, field borders, icons, focus indicators and error messages. Weak contrast can make a function difficult to discover even if it technically works.

As a practical starting point, WCAG requires a contrast ratio of at least 4.5 to 1 for normal text. Large text can have a ratio of at least 3 to 1. Important components and visual states, such as field borders and focus indicators, must also be distinguishable from their surroundings.

Use a contrast tool to measure colour combinations. Do not assess them by eye alone. Check all states, not just the default view:

• Normal, visited and active link
• Button in its normal, focused and disabled states
• Empty, completed and error-marked form field
• Menu item on hover, with keyboard focus and on the active page
• Text over photographs or coloured surfaces

Colour should not be the only cue either. If a field with an error only gets a red border, the problem may be difficult to perceive. Combine the colour with text, a clear symbol and a specific explanation.

The form is often where the user journey stops

Forms bring together many accessibility requirements in a small space. Fields must be labelled, instructions must be understandable, and errors must be handled without the user losing their overview.

A good form has visible labels above or beside the fields. Placeholder text inside the field should not be the only explanation. It disappears when the user starts typing, often has weak contrast and may be interpreted differently by assistive technologies.

Make the requirements clear before the user submits

• Mark required fields both visually and in a machine-readable way.
• Explain format requirements before the field, for example how the date or organisation number should be entered.
• Use the correct field type so that browsers and mobile keyboards can assist the user.
• Only ask for information you actually need.
• Avoid time limits, or allow users to extend the time when a limit is necessary.

When submission fails, the user should receive a summary and specific messages next to the relevant fields. “Invalid value” is not very useful. “Enter the telephone number using eight digits” explains what needs to be corrected.

Do not delete correctly entered information after an error. Consider moving focus to the error summary and let the user go directly to each problem. After a successful submission, the confirmation must be clear both visually and to the screen reader. Explain what was submitted and what happens next.

Distinguish between severity and effort

Do not prioritise errors solely based on how easy they are to fix. First assess the consequences for the user journey.

1. Blocking: The task cannot be completed, for example because the submit button cannot be reached using the keyboard.
2. Serious: The task can be completed, but requires guesswork or an unnecessary workaround.
3. Disruptive: The solution works, but provides poor orientation, unclear cues or extra work.
4. Improvement: The change will make the solution easier to use, even though the current solution does not necessarily block the task.

Record each finding with its location, steps to reproduce, expected result and actual result. Feel free to include a screenshot, but do not let it replace the description. A developer must be able to reproduce the problem without interpreting a vague comment such as “works poorly with keyboard”.

Make testing part of the workflow

Accessibility becomes more manageable when the team regularly tests small user journeys. Designers can check contrast, focus and error patterns before development. Developers can test components with a keyboard and screen reader. Content owners can quality-assure headings, link text, field labels and alternative text for images.

For larger changes, the selected user journey should be tested again from start to finish. A new menu, information box or consent solution can create barriers somewhere entirely different from where the change was made.

Automated tools are useful for detecting some code and contrast errors, but they cannot determine whether the focus order is logical, whether an error message is understandable or whether the task feels coherent. That requires manual testing.

Start with the journey that matters most. When it works without a mouse, makes sense when read aloud and handles errors in an understandable way, you have improved more than you would through a long list of isolated minor fixes.