Build a WordPress navigation menu that works on mobile and with a keyboard

Identify which menu you are editing

With a block theme, navigation is usually edited through the Site Editor and a Navigation block. Classic and some hybrid themes use Appearance → Menus, with theme locations determining where a saved menu appears. WordPress documents that distinction in the Menus screen guide.

First open the public page and identify the header or navigation region you intend to change. Then locate its corresponding template, template part or menu location. A site can have several menus, and changing a footer menu does not necessarily change the mobile header.

Record the current labels, destinations and submenu relationships. If desktop and mobile use separate menu instances, note that explicitly. Keep their wording and destinations consistent unless there is a clear reason for a difference; a compact layout should not quietly remove the only route to an important page.

Navigation also differs from homepage assignment. A menu item labelled Home can still point to the wrong page. Our homepage and blog-page guide explains how to check those roles separately.

Keep the structure understandable before styling it

For a fictional repair business, Home, Services, Maintenance guides and Contact may explain the site’s main routes more clearly than Explore, Discover and More. Put related service pages under Services only when the grouping helps visitors. A deep tree is harder to scan, open and maintain.

WAI’s menu structure guidance describes meaningful list structure, navigation landmarks, short region labels and an indication of the current page. Those semantics help assistive technologies communicate relationships that visual indentation alone cannot supply.

If a page contains primary navigation, article pagination and footer navigation, make those regions distinguishable. “Primary” and “Article pages” are illustrative labels with different purposes. Repeated copies of the same navigation can use the same label; different collections should not all be indistinguishable.

Review link wording in context. “Maintenance guides” describes a destination; a row of unrelated links all labelled “More” forces additional investigation. WAI’s link-purpose explanation describes identifying what a link does from its text or associated context.

Configure native WordPress controls deliberately

In the Navigation block, select the intended menu and use List View to inspect its items. Edit each label and destination, then review the submenu and overlay settings. Current WordPress offers overlay visibility choices of Off, Mobile and Always, and can show text labels for Menu and Close instead of an icon. See the Navigation block documentation.

Check whether the block is still displaying an automatic Page List or a curated collection of links. WordPress documents that converting the Page List to individual links stops automatic addition of newly published pages. Choose which behaviour you want rather than discovering it after an unrelated page appears in the header.

For a classic theme, save the menu and assign the intended display location. Use supported controls before adding a second navigation plugin. If the current theme cannot provide the behaviour you need, identify that specific limitation and evaluate a replacement in a test environment.

When saving shared header work, review the affected templates or items. Test more than the homepage: articles and category pages may use a different header or menu instance.

Separate a destination link from a submenu control

A parent item can have two different jobs: visit a section overview or open its child links. Make those actions understandable. If Services is a real overview page, its link should lead there; a separate, clearly named control can expose the child pages. If the item only expands a group, it should behave as a control rather than a broken link.

Do not use an empty destination or a bare # as a substitute for deciding the interaction. On a phone, a visitor tapping Services should not have to guess whether the first tap opens children and a second tap navigates away.

WAI’s fly-out menu guidance discusses keyboard access and the distinction between parent links and submenu toggles. Hover can supplement navigation, but hover alone is inadequate for a touch screen or keyboard user.

For a developer reviewing custom output, an ordinary site navigation does not automatically need the ARIA menu or menubar role. WAI’s disclosure navigation example uses links and disclosure buttons instead. Its code is illustrative and requires testing; pasting ARIA attributes into an existing theme is not a substitute for implementing the corresponding behaviour.

Keep focus visible, and handle an overlay according to its design

A focus outline is useful information, not an unwanted decoration. WAI’s Focus Visible explanation describes the need to see which element receives keyboard input. Avoid removing outlines globally to make a screenshot look cleaner.

Check focus over each background and state: normal, hover, selected and expanded. A sticky header or cookie banner must not completely hide a focused control. WAI’s Focus Not Obscured guidance explains that minimum requirement; keeping the whole control visible is a useful design aim.

An overlay implemented as a modal dialog has a different focus model from an inline expanding list. WAI’s modal dialog pattern describes moving focus inside, keeping its tab sequence inside while open, providing a close action and normally returning focus to the opener. Escape closes that pattern.

An inline, non-modal disclosure should not acquire a modal focus trap merely because it contains links. Identify the actual interaction before fixing it. A visual overlay that claims to be modal while keyboard focus moves unnoticed through the page behind it is a defect to investigate.

Check touch targets, wrapping and visual states

Test the menu on a real phone as well as in a narrow browser window. Open the overlay, expand a group, scroll to the last item and close it. Try a long label and text zoom; controls should remain reachable without overlapping or clipping.

WCAG 2.2’s AA target-size criterion uses a 24 by 24 CSS-pixel minimum with specified exceptions, including a spacing alternative. It is not a universal statement that every link must be 44 pixels tall. For important menu controls, give visitors generous usable space rather than designing around the smallest possible exception. See WAI’s target-size explanation.

WAI’s reflow guidance addresses presentation at narrow equivalent widths, including 320 CSS pixels for ordinary vertically scrolling content. Use narrow-width and zoom checks to find lost items, rather than simply shrinking every label until it fits on one line.

Check readable text and controls in hover and focus states, not just the initial screenshot. A dark hover background with dark text can break a menu that looked clear at rest. WAI’s text contrast guidance explains the relevant contrast requirements and exceptions.

Do not forget the navigation below an article list

A header menu can work perfectly while older articles remain unreachable. For a Query Loop, inspect its Pagination block and test the previous, next and page-number routes when enough posts exist. WordPress documents these nested controls in its Pagination block guide.

Keep the direction understandable to both visual and assistive-technology users. If arrows replace visible wording, confirm the links still have useful accessible names. Check the current-page indication and the first/last-page state. A numeric strip that is horizontally scrollable also needs keyboard reachability and visible focus as it scrolls.

Use the public list, not only the editor preview. Follow the next page, open an older article and use the browser’s Back action. Confirm the selected filters and content remain coherent.