Test the inquiry journey with a keyboard

The decision this workflow supports

A staff member can discover practical navigation problems by trying the guest journey without a mouse. The goal is to identify blockers in the actual restaurant form, not to declare the whole website compliant after a quick check.

Put the review process in place

Start at the page and use keyboard navigation through menus, the form and any confirmation panel. Note where focus appears, whether controls can be operated and whether the visitor can leave an overlay. Give reproducible steps to the website maintainer.

Worked example for your team

Start a fictional catering inquiry from the homepage using only the keyboard. Open the navigation, reach the form, move through its fields and submit a test request through the approved review process. If a consent or information panel opens, check whether focus remains understandable and whether the panel can be closed. Record the exact control where progress stops. The maintainer needs those steps to reproduce the issue. After a correction, repeat the same journey rather than assuming the repair worked because the button now looks different.

Sample wording to approve

“Test scenario: find the catering inquiry, enter fictional event details, correct one field and reach the receipt using only the keyboard. Record any point where the next action is unclear or unavailable.” This wording is a draft for the restaurant owner to approve before use.

Fields for the staff handoff

Staff need page and browser, navigation step, focused control, blocker observed, and assigned maintainer. Mark uncertain details explicitly and keep the requested action separate from anything restaurant staff have already confirmed.

Acceptance tests before use

Focus remains visible during the journey. A dialog can be left without a mouse. The submit action is reachable and does not trap the tester. Record the observed result, assign any mismatch, and repeat the affected scenario after correction.

Related guides