Search topics
Menu-only sites with no search or site map
A shop's only way to its products is a menu of categories, so anyone who can't guess which category holds an item has nowhere else to look.
The problem
People who can't guess which menu category holds what they want have no other way to find it.
A homeware shop sells around 300 things, filed in its menu under Shop: Kitchen, Table, Bath and Bedroom, each opening into its own categories. Someone who wants linen napkins tries Kitchen, because the linen tea towels are there, then Bedroom, because that is where the linen sheets are. The napkins are under Table, Linen. There is no search box in the header, and the footer has Delivery, Returns and Contact us, but no site map. The home page shows a few featured products, but not the napkins. The menu is the only way to them, and to every other product, category, care guide and policy page.
Success criterion 2.4.5, Multiple Ways, at Level AA, asks for more than one way to locate a web page within a set of pages. W3C's sufficient techniques name the ways, of which a site needs two or more: links to related pages, a table of contents, a site map, a site search, a list of links to all pages, or, on a very small site, links to every page from the home page. Here every page has exactly one way in, the menu, so every page fails. The featured products on the home page are a second way only to those few products, not to the rest.
The criterion has one exception: a page that is a step in a process, or its result, such as the delivery step of checkout or the order confirmation, doesn't need a second way in. Product pages, categories and help pages are not steps; anyone can arrive at them from anywhere.
A menu is one person's way of sorting things, and it works only for people who sort them the same way. Very small sites need less: when the home page links to all three or four pages, W3C says links to and from the home page can be enough.
4 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited language, cognitive and learning abilities Finding napkins by menu means guessing that the shop filed them under Table rather than Kitchen or Bedroom. People who find categories hard to predict, or who don't remember where they found something last time, go round the menu again and again. A search box lets them use their own word.
- Without vision A screen reader reads a big menu one item at a time, and each category opens another list. Searching, or jumping to a site map's headings, is often much quicker than listening through every branch.
- Limited vision With a screen magnifier, they see a small part of the page at a time, so they open category after category and scan each list piece by piece. A search field, or a site map that is a plain page, is easier to follow at high zoom.
- Limited manipulation Each menu level is more presses, or more careful pointing for someone with a tremor, and every wrong guess means going back and opening another category. A search word takes them to the page in fewer steps.
The failure is an absence, and no page shows it: each page has a working menu, so axe and other single-page scanners find nothing, and none of their rules covers 2.4.5. EaseWeb's audit looks across the pages of a run, and when none of them has a site search or a link to a site map, it raises a review lead, not a finding: the second way may be links between related pages, a list of every page, or a search the run didn't reach, and only a person can tell whether those reach every page. Whether a search actually finds things by the words people use is for a person to try. A code assistant asked to "improve the navigation" may add more levels to the menu, which is still one way.
Try it
Find the shop’s linen napkins.
On the broken side, the menu under Shop is the only way in. Apply a fix to add a search box, a site map in the footer, or links from one product to the next, and find the napkins again. The panel under the window lists the ways in, and the one you used.
Broken Can you fix this?
Ways to find a page: the menu
The fix
Add a second way to every page besides the menu: a site search, a site map, or links between related pages.
- 1Every page can be reached in at least two ways.
- 2A search or a site map, if there is one, is on every page, in the same place.
- 3Steps in a process, such as checkout, are the only exception.
<header class="site-header"> <a href="/" class="logo">Fernhill</a> <nav aria-label="Main"> <ul> <li> <button type="button" aria-expanded="false" aria-controls="menu-shop">Shop</button> <ul id="menu-shop" hidden> <li><a href="/shop/kitchen">Kitchen</a></li> <li><a href="/shop/table">Table</a></li> <li><a href="/shop/bath">Bath</a></li> <li><a href="/shop/bedroom">Bedroom</a></li> </ul> </li> <li><a href="/sale">Sale</a></li> <li><a href="/journal">Journal</a></li> <li><a href="/about">About</a></li> </ul> </nav> <a href="/basket">Basket</a></header>…<footer> <a href="/delivery">Delivery</a> <a href="/returns">Returns</a> <a href="/contact">Contact us</a></footer>A site search in the header
<header class="site-header"> <a href="/" class="logo">Fernhill</a> <nav aria-label="Main"> … </nav> <search class="site-search"> <form action="/search" method="get"> <label for="site-search">Search the shop</label> <input id="site-search" name="q" type="search"> <button type="submit">Search</button> </form> </search> <a href="/basket">Basket</a></header>The menu itself is well built, but it is the only way to any page. Someone who doesn't know that the shop files napkins under Table can only open each category in turn until they find them.
The search sits in the shared header, so it is on every page in the same place, and the search element makes it a search landmark that screen reader users can jump to. With the menu, it gives every page two ways in. It works only as far as the results do: it has to find every product, category, care guide and policy page by its title, and by the words visitors use for it.
All three pass 2.4.5 when they reach every page. Use the site search: it is the only one that lets people find a page by their own word, without knowing how the shop sorts things, and it reaches every page as soon as it is indexed. The site map and related links pass only while they are complete, and both still follow the shop's own categories. They are worth adding beside the search, the site map especially, since it shows the whole shop at once and works without typing.
What makes a search a real second way is what it finds.
- Index every page people might look for: products, categories, care guides, Journal posts and the help pages, not only products.
- Match the words visitors use as well as the shop's own: plurals, common misspellings and synonyms such as serviette for napkin.
- When nothing matches, say so and offer the categories or the site map, rather than an empty page.
The search results page should state how many results it found, in the page title and at the top of the results; if results update as people type, how to announce them is covered in search and filter results that update without a word. Keep the search in the same place on every page, as the header is shared; moving it from page to page breaks consistency, as navigation menus that change order or names between pages explains.
A search field that only appears after pressing a magnifier icon is fine, as long as the icon is a button named Search and the field takes focus when it opens.
An XML sitemap for search engines, at /sitemap.xml, is not a site map for people. It doesn't count as a way to find a page, and linking to it from the footer doesn't help anyone.
Breadcrumbs show where a page sits and link up the hierarchy, but they don't lead to pages people haven't found yet, so they don't make a second way on their own. Filters and sorting on a category page are part of browsing that category, not a separate way in.
A site of three or four pages, all linked from the home page and from each other's menu, already offers more than one way. This guide is about sites big enough that a menu becomes a puzzle.
Fixing this with an AI coding assistant? Get this guide as Markdown, or get every guide in your coding agent.
Verify the fix
4 checks, no mouse.
Test with: Keyboard, Screen reader
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after any change to the menu, the search index or the site's sections.
Limits
This is a starting pattern, not a guarantee for every site. 2.4.5 asks for more than one way, not for good ones: a search that finds nothing useful technically passes, and still fails the people it is for. Steps in a process, such as checkout, are exempt, so don't put a search into the payment step to satisfy it. Test the whole site with the people who will use it, especially people who find menus hard.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
- WCAG Understanding: multiple-ways (opens in a new tab)
- WCAG Technique G161 (opens in a new tab)
- WCAG Technique G63 (opens in a new tab)
- WCAG Technique G125 (opens in a new tab)
- WCAG Technique G126 (opens in a new tab)
- developer.mozilla.org: search (opens in a new tab)
- ARIA APG: search (opens in a new tab)
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.