Choose a realistic customer task, then try to complete it without the mouse: find a service, open its page and reach the enquiry route. Watch for a visible focus indicator, a sensible order and controls that can be operated and left using the keyboard. Record the exact point where the task stops rather than reporting only that the website “fails accessibility”.
This is a useful preliminary check for a business owner or designer. It does not replace testing with assistive technologies, people with different access needs or a full accessibility evaluation.
Set up a safe, repeatable task
Use a normal browser and note its name, device and page address. Agree a task that reflects the real site, such as finding a named service and opening its quote form. If a form or booking must be submitted, agree a clearly labelled test with the recipient first; do not create a real booking or send an unexpected message.
Move focus to the browser address bar, open the starting page and put the mouse aside. On a typical desktop browser, Tab moves forward through focusable controls and Shift+Tab moves backwards. Browser and operating-system settings can affect which elements receive focus, so note those settings if the result is unexpected.
Follow the visible focus
Press Tab slowly. At each stop, check that you can see which link, button or field has focus. A focus outline may be subtle, hidden behind a sticky header or indistinguishable from the surrounding colour. Record the control and its state; a screenshot can help a designer find it.
The order should make sense for the task. If focus jumps to the footer before an open navigation menu, or enters content hidden behind a dialog, record the sequence. A jump is a reason to investigate in context rather than proof of a particular technical cause.
Try a link with Enter and operate buttons using the keys appropriate to that control. Test navigation menus, search and any booking widget that the customer must use. A menu available only on mouse hover can prevent someone from reaching the service page.
Check menus, dialogs and the return route
Open the menu or dialog using the keyboard. Can you reach its choices, understand where focus has moved and return to the page? Use the control’s normal keyboard instructions, including Escape where the interface offers it. A keyboard trap occurs when focus can enter a component but cannot be moved away using the keyboard or an explained method.
Check the route back as well as the route in. After closing a dialog, the person should be able to continue from a sensible place. A third-party booking screen or embedded map is part of the customer journey when the site asks visitors to use it; agree who can investigate a problem in that component.
Rehearse the form without sending customer data
Tab through the labels, fields, choices and submit button. Leave a required field empty and, only where an agreed test is safe, try to continue. Can you identify the error and reach the affected field? Does the information already entered remain available where appropriate? The form feedback guide develops the wording and uncertain-submission cases.
Do not assume a message reached the business just because the page says it was accepted. Where a complete test is agreed, confirm the labelled test with the intended recipient. Do not use real customer details or trigger emails to uninvolved people.
Give the maintainer a useful issue report
Record the page URL, browser and device, the task, the keys used, the expected result and what actually happened. “Tab from Services to the booking button: focus is not visible against the banner” is more actionable than “menu broken”. Add whether the problem repeats and whether it blocks the enquiry completely.
W3C’s Easy Checks explain keyboard access, visible focus and the limits of a preliminary review. Use the first-pass accessibility guide for images, headings and other checks. A Formby, Freshfield or L37 business can discuss a website improvement with the page and the task that is difficult.
