A website can look polished and still stop someone from becoming a customer. A menu that opens only on mouse hover, an invisible focus indicator or a booking calendar that cannot be operated from a keyboard can interrupt the route to an enquiry.
Keyboard accessibility gives you a practical way to examine that route. Start with a real customer task, put the mouse aside and work through it. The useful question is whether someone can understand where they are, operate the controls and finish what they came to do.
What should work without a mouse?
Customers should be able to perform your website’s functions through a keyboard interface. W3C’s guidance on keyboard access explains why this matters for people who are blind, have low vision or use alternative input equipment. Keyboard interfaces also support some assistive technologies; access is broader than a standard desktop keyboard.
For a business website, the practical scope includes finding a service, opening navigation, choosing options, completing forms and using booking or purchasing tools. Do not stop at checking whether the homepage’s links receive focus. Follow the task through to its outcome.
Choose the customer journeys before you test
Pick two or three routes that matter commercially. A service business might test finding the relevant service and requesting a quote. A retailer might test choosing a product option, adding it to the basket and reaching checkout. A bookings business should include choosing a date and changing that choice.
Include the less convenient states: a cookie banner on a first visit, an expanded menu, an unavailable appointment and a form with an error. These are part of the experience customers actually encounter.
Use a test environment for submissions, orders and bookings wherever possible. Arrange test enquiries with the receiving team and use the payment provider’s test mode for purchases. The exercise should not create an accidental booking, charge or customer message.
Run a first keyboard check
Open your chosen starting page in a browser with keyboard navigation enabled. If Tab appears to skip ordinary links, confirm the browser’s navigation behaviour before treating that as a website fault, particularly on a Mac. Record the browser and operating system used so another tester can repeat the check.
- Put the mouse aside and use Tab to move forward between controls.
- Use Shift plus Tab to move backwards.
- Use Enter to activate links. For buttons, test the expected Enter and Space behaviour.
- Use arrow keys where appropriate within controls such as option lists or calendar widgets.
- Open and close menus or dialogs, then continue the original task.
W3C’s button pattern describes Enter and Space activation. Complex widgets can use arrow keys internally, so a calendar is not automatically broken because Tab does not visit every date. What matters is a usable, discoverable keyboard route through its functions.
Check the points where customers can get stuck
1. Navigation opens and remains usable
Try every part of the menu needed for your chosen task. Can you open a dropdown, reach its links and move on? Does a submenu disappear before you can select anything? Can you close an overlay menu without clicking outside it?
Repeat the check at a narrower browser width, where the layout may switch to a mobile-style menu. W3C’s keyboard-control guidance explicitly includes mobile menus operated through keyboard interfaces. A working desktop menu does not establish that the smaller layout works too.
2. You can see where the next action will happen
The currently selected link, button or field needs a visible focus indicator. This might be an outline, border or other clear change. Watch it as you move: can you confidently identify the control that Enter would activate?
Look across the site’s different backgrounds. An indicator that is obvious on a pale form may disappear on a dark navigation bar or photograph. W3C’s Focus Visible guidance says the indicator must remain visible while focus is shown. A brief flash followed by no visible indication is not a dependable way to navigate.
3. The order makes sense
Follow the sequence through a page and then backwards. Moving from the service introduction to its action button and onward to related content should remain understandable. Unexpected jumps into a hidden menu, unrelated footer controls or another section deserve investigation.
The requirement is a sequence that preserves meaning and operation, rather than an exact match to every visual position. W3C’s Focus Order explanation recognises that more than one logical order can work. Record the point at which the sequence becomes confusing and the task it disrupts.
4. Banners do not hide the control you are using
Keep cookie banners, sticky headers and chat prompts in the test. A control can receive focus while sitting behind one of these layers, leaving the customer unsure where they are.
WCAG 2.2’s AA criterion Focus Not Obscured (Minimum) requires that author-created content does not entirely hide a component when it receives focus. Partial obstruction can meet that minimum, but keeping the whole control visible is a better design target. Test the actual overlap rather than assuming that a sticky header is harmless.
5. Pop-ups have a keyboard exit
Open a booking dialog, gallery lightbox or other modal window. Check that focus moves inside it, its controls work and it can be closed with the keyboard. After closing, you should return to a sensible place in the task.
There is an important distinction here: keeping Tab navigation inside an open modal is expected behaviour. W3C’s modal dialog pattern describes this containment, Escape to close and usually returning focus to the opening control. A keyboard trap occurs when the user cannot leave through an available keyboard method. Do not report every contained dialog as a fault.
6. Forms work when something goes wrong
Complete the form, including option selectors and checkboxes. Then deliberately leave a required field empty or enter an invalid email address in the test environment. Can you find the problem, reach the relevant field and correct it without starting again?
Check the result after a valid submission too. A customer needs to know whether the enquiry was sent. W3C’s form notification guidance recommends clear error descriptions, instructions for correction and feedback on success. Ask your developer to check that dynamic messages are also conveyed appropriately to assistive technology; seeing a message yourself does not establish that.
Include the booking tool and other embedded services
Your main website may work while an embedded appointment calendar, payment step or chat widget fails. Test entry into the embedded service, the task inside it and the route back out. Include any new window or external page the customer must use.
If the problem belongs to a supplier’s component, capture it and raise it with that supplier. Ask for a demonstrated keyboard route through the affected task. A general accessibility statement is less useful than a repeatable answer about the exact component you use.
Provide a clear alternative contact route while a blocker is being fixed. That can help customers now, but keep the original journey on the repair list.
Give your developer evidence they can act on
A useful report connects a fault to a customer task. For example: after opening the service menu, Tab moves to the footer and the submenu links cannot be reached. That is much easier to investigate than saying the navigation feels wrong.
For each issue, record:
- The page address, browser, operating system and window width.
- The task you were attempting and the starting state.
- The keys pressed before the problem appeared.
- What happened and what you expected to happen.
- A short recording or screenshot where it helps explain the fault.
Prioritise faults that prevent completion, then issues that make position or navigation difficult to understand. Include shared components such as the header and enquiry form early because the same behaviour may appear across several pages.
Once repaired, repeat the original steps and finish the whole journey. Test after changes to menus, forms, booking tools or templates; include these checks in your WordPress update testing where relevant.
What does passing this check tell you?
It tells you that the journeys you tested were operable under the conditions you recorded. It does not establish that the entire website meets WCAG, works with every assistive technology or satisfies every accessibility need.
Automated tools are useful alongside manual review. W3C’s evaluation-tool guidance explains that they cannot check every aspect automatically and require human judgement. A wider assessment should include other accessibility requirements, appropriate assistive-technology testing and input from disabled users.
As checked on 4 October 2026, WCAG 2.2 is a published W3C Recommendation. W3C’s WCAG 3 introduction, updated in September 2026, confirms that WCAG 3 remains an incomplete draft and recommends meeting WCAG 2.2 now. You can address the barriers in your current customer journeys without waiting for a future standard.
Make the route to enquiry usable
Start with one valuable journey and follow it all the way through. If a customer cannot open the menu, correct an error or select an appointment, you have a concrete issue to fix.
BuzzBoost brings web design and development together around how customers use your site. Tell us which journey you want to improve, and we can discuss the checks and development work it needs.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
