Digital transformation baseline · Article 7
Three Menus, One Navigation
Responsive design usually means one navigation that looks different at different sizes. The old site built three separate navigations instead — one per breakpoint — and left all three sitting in the page at once, visible to nothing but a screen reader, which read every single one.
Seventh in the digital transformation baseline series.
Sighted visitors saw one menu, sized correctly for their screen — the same experience every responsive site aims for. What was actually in the page's own code was three separate navigations, one built for each breakpoint, all three present in the document at the same time.
How this looks fine and reads broken
Visually, this pattern is invisible: CSS shows the desktop menu on a wide screen and hides the tablet and mobile versions, then swaps which one is hidden as the viewport narrows. A sighted visitor at any single width only ever sees one menu, correctly. Nothing looks wrong.
A screen reader doesn't read a page the way CSS displays it — it reads the document. Content hidden only by CSS display rules, without the specific attribute that removes it from the accessibility tree as well, is still announced. So a screen reader user landing on any page of the old site heard the full site navigation, then heard it again, then heard it a third time, before reaching the actual content of the page they came to read. Three chances to get lost in the same menu before the page even starts.
The gap this exposes
Visually correct and structurally correct are two different bars, and a design review only ever checks the first one.
Why three menus happen in the first place
Building a separate navigation per breakpoint is a common, reasonable-looking shortcut — style each one for its own context rather than working out how one structure needs to adapt across all of them. The problem only shows up once you stop looking at the page and start listening to it, which is exactly the review step this kind of defect depends on nobody taking.
What actually closed it
The rebuild's navigation is one set of markup, once, in the page source — for every visitor, at every screen width. What changes between mobile and desktop is purely how that single navigation is presented: a toggle button reveals it as a panel on narrow screens, an inline row on wide ones. There's no second or third copy anywhere for a screen reader to encounter, because there's no second or third copy anywhere, period. The distinction between "hidden from view" and "not present in the document" stops being something a reviewer has to catch by ear, because the structural fix removes the possibility rather than papering over it.
The through-line
This is the same lesson as everything else in this series wearing different clothes: a page that looks correct to the person building it and a page that works correctly for everyone visiting it are not automatically the same claim. The gap between them is exactly the part a purely visual review will never catch — which is why this project tests by listening to the page, not just looking at it.