To review a mobile website menu, start with something a customer needs to do. Find a relevant service, check where to visit or reach the right enquiry page. Follow that route on a phone and record the point where it becomes unclear or stops working.
Opening and closing the menu once will tell you very little about those tasks. A panel may slide into view smoothly while its labels send people to the wrong place. Your review should give the designer a problem they can reproduce, rather than a general request to make the menu simpler.
Choose the task before opening the menu
Write one short instruction in the customer’s language. For a garage, it might be: “Find out whether this business repairs bumpers and how to ask for an assessment.” Avoid naming the menu item you expect the person to choose. That would test whether they can follow your directions, rather than whether the route makes sense to them.
Choose a realistic starting page as well. A visitor may arrive at a service page from an advertisement or search result, so a homepage-only check can miss a problem elsewhere. Keep the starting URL in your notes so you can repeat the same task after a change.
If a colleague helps, let them try without coaching. Record where they hesitate or ask a question. One person’s experience is useful evidence of an observed obstacle; it does not tell you how often every customer encounters it.
Three fictional tasks for a garage website
These scenarios describe an invented garage. They are examples of review notes, not tests of a ZXP client website or measured business results. The suggested repair is a question to investigate, not a change to make without checking the rest of the site.
| Customer task | Observed obstacle | Question for the designer |
|---|---|---|
| Find bumper repair from the homepage | The menu says “Solutions”; the visitor opens two unrelated pages before finding repairs | Would a clearer service label or grouping make the destination easier to predict? |
| Check where to bring the car from a repair page | The menu opens, but a fixed panel covers the location link | Can the link remain visible and usable at this phone size, including when text is enlarged? |
| Reach the assessment form from the location page | “Book now” leads to a general enquiry with no appointment selection | Should the label describe an assessment request, or is the intended booking destination missing? |
Notice that these are different problems. Renaming a link may address the first. It will not uncover a control hidden behind another panel or settle what the business can promise about an appointment. Keep each observation separate so a cosmetic change is not mistaken for a complete repair.
Check the controls as well as the labels
On the phone, open the menu, expand any relevant section and follow its link. Then return and close it. Check whether you can tell which sections are expanded and where you are in the site. The W3C menu tutorial explains why identifiable states and understandable navigation matter.
Compare the same route on a wider screen. The layout can change, but a destination should not acquire an unrelated label or lead somewhere else merely because the screen is smaller. W3C’s menu structure guidance recommends consistent wording, order and destinations for items that appear across screen sizes.
A keyboard check is a separate task. On a computer, use Tab to reach the navigation and watch the visible focus indicator. Try the controls without relying on a mouse hover. If a submenu cannot be reached, or focus disappears behind the open panel, record the exact step for the developer. W3C’s fly-out menu guidance provides implementation detail for that review.
Do not assume every website needs the same menu pattern. A small service site and a large catalogue have different information to organise. A familiar icon is only useful when the controls and destinations behind it work for the task.
Look for collisions in the space people actually use
Check the menu with the other visible controls on the page. A consent notice, chat invitation or fixed contact bar can compete for the same space. Try the task before and after dismissing a dismissible panel, and note whether a link is covered or a close control becomes difficult to reach.
Enlarge text where the device or browser supports it, then repeat the task. Also check page zoom separately where available. Record which setting you used: enlarging only text and zooming the whole page are different checks. A zoomed desktop window is not a substitute for trying the website on a phone.
These checks can reveal a real defect, but passing them is not an accessibility certification. W3C’s Easy Checks describes an initial review and makes clear that a broader evaluation is needed to assess accessibility comprehensively.
Send a repair note that can be repeated
Give your designer the starting URL, device and browser, the task, the actions you took and what you saw. Add the text-size or zoom setting if it matters. A screenshot helps show an obstruction, while a short screen recording can show a menu closing before you can select an item. Avoid recording personal details or a real customer’s message.
For the fictional location problem, a useful note would be: “On the bumper-repair page, I opened the menu to find the address. The bottom location link sat behind the fixed contact panel. I could see part of the label but could not use it without dismissing the panel.” That gives the developer a specific state to reproduce. “The mobile menu feels wrong” does not.
Agree on what a successful repair should let the visitor do. After the change, repeat the original task under the same conditions, then check the surrounding routes so the fix has not made another destination harder to reach. Keep the first observation and the later result together.
If the route works but the destination never answers the customer’s question, the next issue is the page content. A menu cannot supply a missing service explanation or an unconfirmed address. Bring the task and your notes into a discussion about ZXP’s website services so the work can address the actual gap.
Sources & references
- 04Easy Checks — A First Review of Web Accessibility
W3C Web Accessibility Initiative
A perspective from the ZXP team.
Designed to help you ask better questions and take a clearer next step.
