Start with the actual page set
A service page can be perfectly readable and still be effectively hidden if the only route is a menu label the customer would never guess. WCAG 2.2 success criterion 2.4.5 asks for more than one way to locate a page within a set of pages, with an exception for pages that are the result of, or a step in, a process. This is a finding task: can a person who begins with a different mental model arrive at the same information? A second visual copy of the same menu is not necessarily a genuinely useful second route if it demands the same choice at the same point.
First draw the boundary of the page set. A business site may have English and Traditional Chinese versions, a separate blog, a customer account area and checkout. The W3C explanation treats language versions as different sets of pages. Audit the ordinary public service pages in each language rather than counting an English route as the second way to a Chinese page. Record the actual URLs, their published titles and which pages are normal information pages. A payment confirmation generated after an order is different: asking the visitor to find that specific result through a public site map would misunderstand the process exception.
Choose a page a customer actually needs before contacting you, such as an appointment cancellation policy or a service eligibility explanation. Begin from the site's home page without using a stored direct link. Follow the main service navigation and record every label chosen. Then restart and try a materially different route: a site search, a useful site map, a related-information link from another page, or a complete home-page list on a very small site. The two routes need to reach the same current page in the same language. Write down where each route succeeds, stalls, or leads to an obsolete copy.
Do not turn the criterion into a demand for a costly search product. The W3C examples include related links, a table of contents, a site map, a search function, lists of all pages and links from a home page. A five-page consultancy site can often offer a clear services list plus contextual links between related services. A large catalogue may need both category browsing and search because a giant flat list is hard to use. The right pair depends on the size and vocabulary of the site, but both routes must actually work for the pages being assessed.
Build useful alternative routes
A site search is an alternative only if its index contains the page and its result label tells the visitor where they will land. Test terms customers use rather than only the internal service name. A customer may search for 'change appointment' while the team calls the page 'booking amendments'. Test both English and Traditional Chinese on their respective site sets. Search that returns a generic homepage, an expired policy or a blank result for a common term has not solved discovery. If the search is new, also check that its input, submit action and result list can be used without a mouse.
Related links need a real relationship. A cancellation page linked from appointment details makes sense because readers often move between those questions. A footer packed with every page may technically expose links while burying the route in noise. Use labels that name the destination, and maintain one canonical information page so the menu, related link and search result do not disagree about current terms. Where the business has several branches, consider whether the link is to the general service policy or a branch-specific page; route people to the correct answer rather than merely another page with a similar title.
For a small site map, group pages by customer question rather than copying an organisation chart. A visitor looking for repair eligibility should see a path from 'Repairs and support' even if the internal owner is an operations team. Keep the site map or index page in the same language as its links. If a page is added or renamed, update this route at the same time as the primary navigation. A static list becomes unreliable when it leads to redirects, missing pages, or similarly named archived material, so put it into the normal content maintenance checklist.
Consider a worked example. A small clinic publishes a public page explaining who can book a particular screening service. The main route is Services, Screening, Eligibility. A second route could be a 'Who can book?' link from the screening overview or a search result for the common local term. Test with a reader who knows only the question, not the service category. If they reach an old promotion instead, fix the index or related link. The specific service and pages in this scenario are illustrative; the test should use your own live content and not be reported as a measured customer outcome.
Audit the route, not just the link
Create a simple matrix with one row per ordinary information page and columns for route one, route two, language, last checked date and result. A pass requires someone starting from a reasonable entry point to find the current page using both routes. Merely finding the URL in source code, or using a browser bookmark you already know, is not a discovery route offered by the site. Sample high-value pages first: prices, scope, eligibility, contact, changes and aftercare. Then include pages that sit deepest in navigation, because they are more likely to reveal a hidden dependency on one guessed label.
Run the journey at desktop and narrow mobile width. Mobile navigation may collapse categories and remove a related link that exists on desktop. Use keyboard navigation at least once and inspect the visible result titles, because a route that exists only through hover will not serve everyone. Check both locale versions independently. If an English page has two paths but the Chinese version is absent from the search index, do not mark the whole bilingual journey complete. Record the actual URL reached, so duplicate pages and redirects become visible instead of being silently counted as success.
The process exception should be applied narrowly. Checkout steps, a custom quote generated from answers, or a confirmation tied to one transaction may only make sense inside the process. The static explanation of fees before checkout is a different kind of page and should be discoverable. Avoid labelling every difficult-to-find page a 'process page' simply because it has a button. Ask whether a visitor could reasonably need that information before starting an action and whether the page has a stable identity independent of one completed task. That distinction keeps the audit focused on genuine information needs.
An automatic crawl can identify broken links but cannot prove that a visitor understands a route. Give the test person a plain-language question and watch where they look first without directing them. Ask them to find the same page twice from fresh starts, once through the apparent main route and once using an alternative they would naturally choose. Note the words they expected. This is a qualitative usability check, not a claim about search traffic or conversion. It helps the team change labels and placement while the objective URL and policy text remain consistent.
Keep both routes current
The repair is complete only when the alternative stays correct through content changes. Assign the page owner responsibility for updating menu placement, search index terms and related links whenever a service is renamed or withdrawn. Where old URLs redirect, make sure the destination answers the same reader question; a redirect to a general home page can erase the route. Check newly added pages before release and recheck a small sample after changes to navigation templates or search configuration. This turns the criterion into a maintainable publishing habit rather than a one-off audit screenshot.
Decide what to fix first by the consequence of being unable to find the page. An inaccessible eligibility page may lead to an unsuitable booking; an obscured cancellation policy may create avoidable disputes. Put these ahead of a low-stakes company history page. This ordering is an editorial risk judgement, not a W3C priority ranking or measured traffic forecast. When the team cannot fund site search, publish an accessible index of important pages and use clear contextual links, then test those routes. The standard describes an outcome; it does not require every SME to buy the same software.
Before calling the work done, verify a representative English page and its Chinese counterpart separately, including their actual link destinations. Check that the second route can be described in one sentence without relying on knowledge of your internal structure. If staff cannot explain how a customer would find the page from a fresh start, the route probably needs work. Keep the audit table with the content inventory so that page moves, redirects and language updates trigger the same review. The useful result is a customer who can locate the right current answer by a route that makes sense to them.
Before you proceed
- Does each public information page have two working discovery routes in its own language?
- Do both routes land on the same current answer?
- Have process-result pages been distinguished from ordinary information pages?


