Your website menu should work without a mouse

Visitors should be able to open your website's menu, reach a service page and get to the contact route using a keyboard. A dropdown that opens only on mouse hover can leave that journey unfinished.

Picture a customer using Tab to move across the header. They reach "Services," but the submenu stays closed. The links are there for someone with a mouse; this customer cannot reach them through the same menu.

Include keyboard navigation in the website brief and review it on working pages. A screenshot cannot show whether the menu opens, where focus moves or whether someone can leave it.

Give the dropdown an operable control

W3C's keyboard guidance explains why web functionality needs a keyboard route, including for people who cannot use a mouse. For a business website menu, hover cannot be the only way to reach the service links.

Agree what the top-level item does. Does "Services" open a page, expand a list, or have a separate button for expansion? W3C's fly-out menu tutorial describes a separate toggle when the parent item must also link to a page. It also recommends another route to the submenu destinations, such as links on the parent page.

That gives customers a useful services overview as well as a dropdown. Keep both routes consistent when the content changes.

Make the current position visible

Keyboard focus is the control that will receive the next keyboard action. Visitors need to see it. W3C's focus-visible guidance calls for a visible indicator in keyboard operation; removing an outline for a cleaner design can remove that cue.

For a conventional dropdown, a disclosure button can show and hide ordinary navigation links. W3C's disclosure-navigation example uses Tab to move between controls, Enter or Space to toggle the button, and Escape to close the open dropdown and return focus to its button. It explains that typical website navigation does not need the more complex ARIA menu role.

The example is a reference, not production-ready code. The implementation still needs testing with the browsers and assistive technology in the agreed scope.

Review the whole route before sign-off

Ask the developer to demonstrate the menu without touching the mouse:

• Tab to the dropdown control and identify its focus indicator.
• Open it, reach a service link and activate that link.
• Reopen it, close it with Escape and check where focus returns.
• Continue past the navigation, then move backward with Shift+Tab.
• Repeat at a narrow layout with the collapsed mobile menu.

Record any unreachable links, lost focus or controls that cannot be left. These checks cover a specific navigation journey; they do not establish that the whole website meets an accessibility standard.

Rootscratch's web design and development considers keyboard access alongside menus, responsive layouts and clear feedback. For a new site or redesign, bring the pages customers need to reach. Include a keyboard walkthrough of that route in the agreed review scope.