Start with one realistic customer task: find a suitable holiday, choose the dates and send an enquiry. Follow it all the way through. This gives your review a useful boundary and helps the team see where a customer might need assistance.

The checks below are a starting point. W3C’s preliminary accessibility checks can identify some barriers, but they do not provide a complete accessibility evaluation or establish conformance. Plan a fuller assessment when you need that assurance. Source: W3C WAI: preliminary accessibility checks

Define the journey before testing

Choose a representative offer and write down the steps a visitor must complete. Include any search widget, date picker or form supplied by another company. Record who is responsible for each part so findings reach someone who can act on them.

Use fictional customer information and a test route agreed with the team. This lets you examine submission and confirmation without introducing misleading enquiries into normal sales work.

Keep the starting URL, device, browser and test date in the record. Those details make the issue easier to reproduce when a colleague investigates it later.

Try the complete journey with a keyboard

Put the mouse aside and work through the task. Can you open the menu, select the travel dates, change the party size and reach the submit control? Note whether you can see where you are and leave an opened control without getting stuck.

W3C’s keyboard criterion requires functionality to be operable through a keyboard interface without specific timing for individual keystrokes, subject to a limited exception for movement-path input. A travel date picker should be included in the review, not skipped because the surrounding page works. Source: W3C: understanding keyboard accessibility

Write each finding as a reproducible sequence: the starting page, the actions taken, the expected result and what happened. This is more useful to the person fixing it than “the form is difficult”.

Review labels and error messages together

Read the form before entering any values. A label should identify the purpose of its control and be associated with it in the page structure. W3C’s form guidance explains that relationship. Ask the website team to verify it rather than judging by visual position alone. Source: W3C WAI: labelling form controls

Try an incomplete submission in the test environment. Check whether the message identifies what needs attention and explains how to correct it. Then submit a valid enquiry and check the feedback. W3C recommends clear notifications for errors and successful submission. Source: W3C WAI: form notifications

For example, “Enter your preferred departure date” gives a tester a specific correction to assess. Use wording that matches the actual requirement; do not add instructions for fields the form does not need.

Describe images according to their purpose

Review each image in context. An informative photograph, a decorative image and an image used as a button need different treatment. W3C’s image guidance explains when to describe information, when to describe a function and when an empty text alternative is appropriate. Source: W3C WAI: text alternatives for images

For a room photograph, describe only the relevant features you can verify. Do not infer accessibility features from an unclear image. Record any separate product claim that needs confirmation so it is reviewed alongside the picture.

Turn findings into an achievable fix list

For each issue, record the affected step, its effect on the task, the responsible team and the agreed follow-up. Prioritise problems that prevent completion, while keeping other barriers visible for review.

Retest the same journey after a change. Keep the original test steps so you can compare the result directly. Include testing with disabled users and appropriate specialist review in a wider evaluation plan; these preliminary checks alone cannot establish that everyone’s needs are met. Source: W3C WAI: preliminary accessibility checks

Use the linked definitions of keyboard accessibility, form labels and alternative text when sharing the findings. They give colleagues a common explanation without turning the customer’s journey into a technical discussion.

Written and updated by Travelgenix. Sources checked on 16 October 2026. Worked examples and checklists are editorial illustrations and recommendations, not customer results.