AI-Built Navigation: Test the Keyboard Journey

Imagine reviewing an AI-built website for a small creative studio. The Workshops dropdown opens smoothly beneath the pointer, its links look tidy and the colours match the brand. Then someone puts the mouse aside. They reach Workshops with the keyboard, but cannot open it. The visual review has missed the route into the business.

For an independent creator or business owner, a useful review follows a visitor’s task: find a workshop, reach its page and continue to booking. A screenshot cannot demonstrate that sequence. When you ask AI to build or revise navigation, include the behaviour you expect and check it in the working page.

Choose the interaction before requesting the code

This walkthrough concerns a simple dropdown in the page: a button shows or hides a list of page links. A full-screen modal navigation overlay or an application-style menu needs an interaction design appropriate to that component.

The W3C disclosure-navigation example uses page links without the ARIA menu role. It explains that typical website navigation does not need the complex keyboard interactions associated with menu and menubar widgets.

Write a short behaviour brief for the studio before changing anything. Workshops reveals links to upcoming sessions; selecting a session opens its page. Contact is a separate destination. The brief should make clear which control changes what is visible and which control takes the visitor somewhere.

Give the test a named destination: the studio’s hypothetical Saturday linocut workshop. After following its link, check that the page describes that session and has the intended booking route. If it opens an old course listing instead, record a destination fault separately from the keyboard fault. This helps keep a navigation repair from becoming an unnecessary rewrite of the whole site.

Keep destinations and show/hide controls distinct

W3C’s link pattern guidance recommends native HTML links with an actual destination. Adding a link role to another element does not automatically give it standard browser link behaviour. Ask the coding assistant to retain real links for the studio’s workshop pages. Use Enter to follow a focused link in the keyboard check.

For the show/hide control, the disclosure pattern specifies activation with Enter or Space. Its expanded state should reflect whether the controlled content is visible. In code, that state is represented by aria-expanded, set to true when expanded and false when collapsed. The visible dropdown and its reported state should agree.

A useful review therefore asks two separate questions: does the Workshops button operate, and does each workshop link reach the intended page? Finding one successful click does not answer both.

Prepare the browser, then follow the route

Record the browser and operating system used for the check. If tabbing seems to skip links, inspect the keyboard-navigation settings before diagnosing the website. Apple’s Safari guidance, for example, documents different Tab and Option-Tab behaviour and a setting that changes which page items Tab highlights.

For the studio’s proposed disclosure design, use this sequence:

• Reach: move to the Workshops button with Tab and identify its focus indicator.
• Open: activate the button with Enter; repeat separately with Space.
• Explore: use Tab and Shift-Tab to move through the revealed links in both directions.
• Close: press Escape while inside the dropdown; check that it closes and focus returns to its controlling button.
• Continue: tab onwards to Contact and the page beyond the navigation.

This follows the APG example’s basic interaction. Arrow-key support is optional in that disclosure example and supplements tabbing. Avoid judging a different widget by this sequence without first checking its intended pattern.

Make the current position visible

Keyboard focus is the current interaction position. W3C’s explanation of Focus Visible describes why a visible indicator matters: sighted keyboard users need to know which control they are operating. As you follow the studio’s route, look for that indication on the toggle and every revealed link.

Also check the page after scrolling. W3C’s Focus Not Obscured (Minimum) guidance identifies sticky headers and footers as possible obstructions. Its minimum criterion concerns a focused component being entirely hidden by content created by the site. For a more usable design, aim to keep the whole focused item clear.

Consider a hypothetical failure: the first workshop link receives focus beneath a fixed promotional banner. Report the banner, scroll position and affected link. Changing the focus-ring colour alone would leave the overlapping layout unresolved.

Check the way out, as well as the way in

W3C’s No Keyboard Trap guidance requires a keyboard route away from a component that can receive keyboard focus. If leaving requires an unusual method, that method must be communicated. For this ordinary dropdown, test onward movement instead of assuming that opening successfully completes the review.

Give the AI assistant a reproducible correction request. Record the page, starting state, keys pressed, observed result and expected result. For example: “After opening Workshops and reaching the final session link, Tab cycles back inside the dropdown. This disclosure should let me continue to Contact.” This is a fictional failure report, not a finding about a particular product.

After a correction, repeat the complete route and try the mouse or touch interaction too. Preserve the working destinations and labels while checking the changed behaviour. If the session page leads to a form, extend the review using the MaryChuks.com guide to forms people can finish.

Keep a useful release record

Save the tested page version, browser, device, task and remaining issues. That gives the next AI-assisted edit something concrete to preserve. A later header redesign should trigger a repeat of the workshop journey, rather than rely on the fact that a previous version passed.

W3C labels its APG example as illustrative and calls for assistive-technology testing before production use. Treat this keyboard walkthrough as one focused check within a wider accessibility review. The practical outcome is a navigation route someone can follow, leave and use again with confidence.

Sources

• W3C: disclosure-navigation example — page updated 20 January 2026; supporting disclosure and link patterns.
• W3C: Focus Visible and Focus Not Obscured (Minimum).
• W3C: No Keyboard Trap.
• Apple: Safari keyboard shortcuts and gestures.

Guidance checked on 25 October 2026. The creative studio, website and failure reports are hypothetical.