Estimated reading time : 4 min · Published
Start with real tasks
Choose concrete intentions: find a price, compare services, contact someone or return to information seen earlier. Ask people unfamiliar with the site where they would begin. Record first choices and backtracking without guiding them.
Compare menu words with the words visitors use. A label such as “Solutions” may make sense internally yet mean little to outsiders. The service-page guide helps align label, content and decision.
- Tasks and audiences defined.
- First choices observed without help.
- Labels revised after hesitation.
Check several routes
An important page should have a predictable path even when someone arrives directly from search. Test the main menu, contextual links, breadcrumbs and footer. The same service should not acquire different names without a reason.
Deep menus need particular attention: visitors must understand the relation between parent and child items. Do not hide an essential destination behind hover alone, which does not translate to touch screens.
- Key pages easy to reach.
- Contextual links consistent.
- No essential hover-only destination.
Test keyboard and small screens
Use Tab, Enter, Space and Escape as appropriate for each component. Focus must be visible and an open submenu must be escapable. On a phone, test opening, closing, target size and enlarged text.
Try long and short pages. A sticky menu can obscure a heading after an anchor link; a drawer can leave scrolling locked after it closes. The W3C menu tutorial gives structural and interaction examples.
For ordinary site navigation with links and a disclosure button, specify the expected outcome for each of the four states below. aria-expanded describes state; the attribute does not hide links by itself. Check visibility, keyboard navigation and assistive technology output together. A closed panel whose links still receive focus fails this contract even when its screenshot looks correct.
In the disclosure pattern used here, Escape closes the panel and returns focus to its button. This non-modal panel must not trap keyboard navigation. Do not automatically assign menu or menubar roles: those widgets require other interactions. The W3C APG example illustrates a pattern rather than production-ready code; browser and assistive technology testing remains necessary and does not certify the whole website.
- Focus and closing checked.
- Touch targets usable.
- Anchors and scrolling verified.
Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.
| State or action | Expected outcome | Verification |
|---|---|---|
| Closed panel | aria-expanded=false | Hidden links absent from the Tab sequence |
| Open panel | aria-expanded=true | Visible links reachable with Tab |
| Escape from the panel | Panel closes | Focus returns to the disclosure button |
| Mobile to desktop resize | One coherent active navigation | No focusable hidden links or duplicate identifiers |
- W3C APG : Disclosure Navigation
W3C APG, consulted 22 October 2026: disclosure navigation, keyboard operation and example limitations. Resizing is an additional part of our test contract.
Find and fix dead ends
Group findings by effect: missing page, ambiguous label, loop, broken link or unreachable control. Fix journeys tied to actual visitor needs first, then repeat the task with someone who has not seen the change.
After release, review site search, exit pages and repeated questions without overinterpreting one metric. A phone enquiry may reveal a confusing menu. The measurement guide links such signals to testable improvements.
- Dead ends ranked by impact.
- Fix retested.
- Visitor signals reviewed after release.
Test navigation after opening and closing
Open sections by keyboard, follow a destination and return with Back. Check that closed-panel links leave the focus sequence and useful context returns. Separate a page-opening link from a submenu disclosure control.
Resize while navigation is open. This reveals states carried between desktop and mobile. Record labels that fail to predict destinations and correct them at their source.
Design mobile navigation and submenus · Choose and test tabbed web views
Test return from a menu

Proposed case: a mobile submenu opens but closing does not return focus to its trigger. The visitor loses their starting point.
Test opening, level changes and closing with different input methods. Keep link order, panel state and return path; a visible menu does not establish controlled navigation.
- Identify the trigger
- Test entering and leaving the panel
- Check return to context
- Test a keyboard journey
Test website accessibility through real tasks
Reference documents
- W3C menu tutorial · Source consulted
Content updated on
Documented reference points for this topic
| Reference | Value or syntax | Scope |
|---|---|---|
| WCAG 2.2 · 2.5.8 | 24 × 24 CSS px | A smaller target can satisfy the criterion through spacing; other exceptions apply. |
| WCAG 2.2 · 1.4.10 | 320 CSS px | Vertical content without two-dimensional scrolling; exceptions cover inherently two-dimensional content. |
Dates indicate when references were consulted. These facts are neither a site audit nor an overall compliance statement.
