Put your mouse aside: Test the most important customer journey for accessibility

A website can look neat and still be difficult to use. The problem often becomes apparent only when someone navigates without a mouse, enlarges the content, uses a screen reader or encounters an error message in a form.

An effective way to find such barriers is to test one important customer journey from start to finish. This could mean submitting an enquiry, booking a service, finding contact information or completing a purchase. The goal is not just to check individual pages, but to find out whether the user can actually complete the journey.

Choose one task that matters

Start with a specific task that both the organisation and the user depend on. For example, a company website could be tested with the task: Find the right service, read what it involves, and submit an enquiry.

Write down the starting point and what counts as completion. This makes the test more precise and reduces the risk of simply clicking around at random.

• Start on the same page where a typical visitor is likely to land.
• Use the actual menu and the visible options.
• Go through the entire form, including validation and confirmation.
• Note where the user has to guess, go back or switch input methods.

This scope makes accessibility manageable. You get a real customer journey to improve, not just a long list of isolated issues.

First review: Use only the keyboard

Put your mouse aside and use Tab and Shift+Tab to move between interactive elements. Use Enter or the spacebar to activate links and buttons. In some components, such as radio buttons and menus, the arrow keys may also be necessary. Escape should normally close dialog boxes and open layers.

At all times, it should be possible to see which element has keyboard focus. A weak or missing focus indicator turns navigation into guesswork. Focus must be visible against the background and remain discernible when it appears over images, coloured areas or buttons.

Check the order

The focus order should follow the visual and logical order of the page. If the keyboard jumps from the main menu to the footer and then back to the main content, the structure is difficult to understand.

Pay particular attention to content that has been visually repositioned through design or layout. What appears to come first may occur much later in the technical order. The solution is usually to tidy up the structure, not to force an artificial order.

Test open and closed states

Open mobile menus, drop-down menus, filters, information boxes and dialog windows using the keyboard. Check that they can be closed again and that focus returns to the element that opened them.

A dialog box must not send keyboard users on to content hidden behind the box. At the same time, users must be able to get out without reloading the page. Such focus traps are among the barriers that can stop a task completely.

Use WCAG to explain the problem

WCAG provides criteria for accessible content, but the criteria are most useful when linked to what the user is trying to do. “The focus indicator is difficult to see” is more actionable than simply recording a criterion violation. Even better is to describe the consequence: “The user cannot see which button will be activated in the next step of the form.”

Distinguish between problems that stop the task, problems that make it substantially more difficult, and minor improvements. This prioritisation helps developers, designers and content managers fix the most important issues first.

• Blocking: A menu, button or form function cannot be used with the keyboard.
• Serious: The focus order is illogical, error messages are not communicated, or the contrast makes text difficult to read.
• Improvement: The content works, but the structure, help text or wording could be clearer.

Check contrast in real situations

Contrast testing must cover more than black body text on a white background. Examine links, buttons, help text, error messages, form fields, icons and focus indicators in all states.

For normal text, the usual minimum requirement is a contrast ratio of 4.5 to 1. Large text can have 3 to 1. Visual parts of the user interface, such as the border of a required form field or a focus indicator, normally need at least 3 to 1 against the adjacent colour.

Do not rely on colour alone. If a field with an error only gets a red border, the meaning may be lost for users who cannot perceive the colour. Add a clear symbol or text explaining what needs to be corrected.

Also test states that are often overlooked: a disabled button, a visited link, text over images and buttons when the pointer hovers over them. Good contrast in the default state is of little help if the text becomes unreadable when the user actually interacts with the element.

Second review: Listen with a screen reader

A brief screen reader test can reveal problems that are not visible. First, listen through the headings. They should provide an understandable summary of the page and be arranged in a logical hierarchy. Headings should describe the content, not be used simply because a particular font size suits the design.

Then go through the links and buttons. Texts such as “Read more”, “Click here” and several identical “Select” buttons provide little meaning when read without their surrounding context. Use names that explain the destination or action, such as “Read about the accounting service” or “Select the standard subscription”.

Images that convey information must have a short and relevant text alternative. Decorative images should not create unnecessary verbosity. Icon buttons need an accessible name that explains their function. For example, a search icon should be announced as search, not as an image filename or an incomprehensible symbol.

The screen reader test should not be used to seek identical announcements in every program. Instead, ask whether the user receives the right information, in the right order, and can understand and complete the task.

The form is often the decisive test

A form brings many requirements together in one place: keyboard navigation, contrast, understandable language, technical structure and clear error handling. It is also where a potential customer can be stopped just before reaching the goal.

Give every field a visible label

The field should have a label that tells the user what to enter. Do not use placeholder text as the only label. It disappears when the user starts typing, may have poor contrast, and provides limited support when correcting errors.

Explain format requirements before the user submits the form. If an organization number, telephone number or password must follow a specific pattern, this should be stated next to the field. Mark required fields both visually and technically, and explain what the marking means.

Make errors easy to find and correct

Submit the form with empty or incorrectly completed fields. The error message should identify which field has a problem, what the problem is, and how it can be resolved. “Invalid value” is rarely sufficient.

The error must be associated with the correct field so that the screen reader conveys it. When there are multiple errors, a summary at the top of the form can provide an overview. If focus is moved to the summary, the user must be able to go directly to the fields that need correcting.

Finally, check the confirmation. The user should understand whether the submission was successful, what happens next, and whether any action is expected. A green checkmark alone is not a clear confirmation.

Document findings that can be acted on

A problem is easier to fix when the description contains more than “does not work”. Use a consistent, concise structure:

1. Describe the page and task that were tested.
2. State the method of interaction, such as keyboard or screen reader.
3. Explain the steps that trigger the problem.
4. Describe what actually happens.
5. Describe what should happen for the task to work.
6. State the consequence for the user and the priority for fixing it.

A specific finding could be: “When the user opens the contact form and presses Tab from the telephone field, focus moves to the footer. The Submit button therefore cannot be reached using the keyboard.” This gives the developer a clear starting point and the tester a clear result to check after the fix.

Fix the pattern, not just the individual page

When an error is found in a shared component, it should be fixed centrally. Poor focus indication on one button is often present on many buttons. The same applies to labels, error messages, dialog boxes and link styles.

Add accessible variants to the design system or component library. Define how focus should appear, how errors should be presented, which contrast levels are permitted, and how components should be operated using the keyboard. This makes accessibility part of the solution rather than a series of local fixes.

Finish by testing the same customer journey again. A fix is only complete when the user can carry out the entire task without encountering the original barrier or a new error created by the fix.

Putting the mouse aside does not solve the entire accessibility challenge. It is, however, a simple way to reveal where design, content and technical structure do not work together. When the test is combined with contrast checks, a screen reader and thorough form testing, the organization gets a concrete picture of whether the website can actually be used.