Begin with tasks and a small information architecture
Information architecture is how content and functions are grouped, named, and connected. List visitor tasks, then map each task’s starting page, next page, and successful end state. This shows whether a menu item is useful or an internal label visitors must decode. Keep primary navigation focused on sections that begin those tasks.
Navigation is not a site map. GOV.UK advises listing useful top-level sections rather than every part of a service. When a journey has a required order, show it in content or a task list instead of making people infer it from a global menu.
Put pages together when visitors expect the same answer or task, not because one team owns them.
Use landing pages and contextual links for detail instead of a dense header.
Use labels that predict the destination
A label is a promise about what follows. Prefer familiar names such as “Pricing”, “Documentation”, “Get support”, or “Manage account” when they match the destination. Avoid vague labels such as “Resources” or “Explore” unless visitors can predict the contents. Keep wording and order consistent.
Google advises concise, relevant link text that is understandable out of context. Generic “click here” and keyword-stuffed links do neither. Give an icon-only control an accessible name that describes its action.
Use “View plans” rather than “Learn more” when the destination is plans.
Mark the active destination visually and programmatically; W3C describes aria-current=page for the displayed page.
Make destinations crawlable and structurally clear
A navigation destination should normally be an HTML anchor with an href that resolves to a real web address. Google says it can generally crawl this form, including dynamically inserted anchors when rendered markup retains that structure. A click handler or custom attribute alone is not a dependable substitute. Inspect rendered output, not only framework source.
Use semantic structure around major navigation. W3C recommends a nav element and, for ordinary site navigation, a list. If a page has several navigation regions, label each so a screen-reader user can distinguish primary navigation from footer or local navigation.
Confirm important desktop and mobile destinations have anchors and href values after client-side rendering.
URL Inspection provides Google crawl, index, and serving information; it does not prove that visitors can find a page.
Design the mobile menu as a complete interaction
Responsive navigation may collapse, but destinations that remain should keep the same wording, order, and target across screen sizes. W3C permits collapsing or hiding items in subnavigation while calling for consistency. Do not make a critical route desktop-only because the header is crowded; relocate lower-priority material or reconsider the hierarchy.
For a show-and-hide menu, use a button to control the link group and communicate whether it is open. W3C’s disclosure-navigation example uses aria-expanded and aria-controls and documents Tab, Shift+Tab, and Escape. It is instructional, so test your component with the combinations your audience uses.
When a parent page and its child links are both needed, distinguish the page link from the control that expands it.
Anything revealed by pointer hover must be discoverable with keyboard focus and touch.
Support orientation and keyboard travel
Keyboard access is not a finishing touch. WCAG 2.1 Success Criterion 2.1.1 requires functionality to be operable through a keyboard interface except for path-dependent input. In a header, visitors should be able to Tab through controls, see focus, activate links and buttons, and move away without a trap.
Repeated header links can make pages slow to traverse. A skip link near the beginning gives keyboard users a route to main content. GOV.UK explains that it is visually hidden until keyboard use activates it. Test that it lands on a meaningful target.
Do not remove the browser focus indicator without a clear alternative that remains visible when zoomed.
Use Tab, Shift+Tab, Enter, Space, and Escape from the header into the destination page.
Test findability before and after release
Ask representative people to complete a realistic task, such as finding cancellation guidance or comparing plans. Watch where they expect to go, which labels they misread, and whether they resort to search because navigation failed them. Do not lead them to the intended label. Record each barrier and the smallest change likely to remove it.
Pair task testing with technical checks. W3C’s Easy Checks recommends testing without a mouse, including focus visibility, tab order, keyboard traps, and dropdowns. Repeat core tasks at narrow widths and larger text sizes. Automated checks can flag markup issues, but cannot establish that a label makes sense.
Record the intended endpoint and supported device or input method before testing.
Test the old and new route against the same tasks rather than relying on stakeholder preference.
Treat navigation changes as availability-sensitive releases
A header can load while a critical path is effectively unavailable: a checkout, login, support route, or documentation page may sit behind a broken state, stale link, or wrong redirect. Before release, inventory critical destinations, test desktop and mobile routes, and confirm rendered links reach the intended page. Use authorized environments for authenticated or regional paths.
SIU’s role is proactive remediation: run a preflight, verify essential paths after deployment, and make correction reversible. Keep a versioned menu configuration, name the person who can restore it, and validate restored paths. This limits release impact; it does not replace usability research or live-status monitoring.
Block publication when a critical destination is missing, wrong, or cannot be reached with keyboard and touch.
Document the prior configuration, owner, trigger, and validation steps before restructuring.