Case study
The Menu That Wouldn't Close
What a free scan found vs. what manual testing found
The business: a UK independent retailer selling stationery and gifts online, including a books section, a standard product catalogue, and a checkout with card payment.
What we tested: homepage, a category listing page, a product page, the cart, and checkout. We ran an automated scan first, the same free type of check anyone can run in seconds, then followed it with manual testing: keyboard-only navigation and NVDA, a free screen reader commonly used for UK compliance testing.
The scan found a solid list of real issues. Manual testing found that, for a keyboard user, large parts of the site are covered up by menus that won't close.
Step one
What a scanner found in seconds
- Serious (3): list items sitting outside a proper list container (9 instances), links with no announceable text and unclear purpose (7 instances), and text with insufficient contrast against its background (2 instances).
- Moderate (2): content sitting outside any landmark region (9 instances), and headings that skip levels.
- Minor (1): one instance of an inappropriate ARIA role.
Nothing critical, and nothing here is unusual for a site of this size, malformed lists, unlabelled links, and heading structure issues are common, fixable, and worth doing. Taken alone, this looks like a moderately tidy site with a manageable snag list.
None of that tells you whether a keyboard user can actually see the page.
Step two
What only manual testing found
Testing by hand, tabbing through every interactive element and listening with NVDA, told a different story, starting with the very first keypress.
Headline finding: a navigation menu that won't close, and covers the page
The site has no working skip link. The very first Tab press on a fresh page load lands on the slideshow's pause button, not on a link to skip past the header, so there is effectively no way to bypass it and get to the content directly.
From there it gets worse. Every navigation category automatically opens its dropdown the moment it receives keyboard focus. To get past the header at all, a keyboard user has to tab through every single dropdown and every sublink inside each one, category by category. And the final dropdown, a large "Books" menu, doesn't close again once you've tabbed past it. It stays visually open, sitting on top of the page underneath. On category pages it covers the entire top row, including the filters. On product pages it covers the entire product.
This isn't a screen-reader-only problem. A sighted keyboard user, someone with a motor impairment using a keyboard or switch device, for example, who can see the screen perfectly well, tabs down to look at a product and finds it hidden behind a menu they have no way to close. Depending on the page, that ranges from a serious obstacle to a full blocker: on a product page, they cannot see or interact with the thing they came to buy at all.
This didn't appear in the scan at any severity. An automated tool checks whether a menu element has the right role and label in the markup; it doesn't tab through it in sequence and check whether something is left open and obscuring the page underneath. That behaviour only shows up when someone actually uses the site the way a keyboard user does.
Second finding: the cart says it's empty when it isn't
Adding an item opens a slide-out cart preview. NVDA announces that the cart has opened, and, in the same breath, announces it as empty, even though the item was just added and is visibly sitting in it.
This is a meaningfully different kind of failure from most of what we find. A missing announcement leaves a screen reader user with no information. This gives them wrong information, actively contradicting what just happened. A screen reader user has every reason to believe their item wasn't added and either tries again, adding a duplicate, or gives up assuming something failed.
The problem compounds inside the cart itself. Changing an item's quantity resets keyboard focus back to the very start of the page, forcing a full re-tab down to the cart every time a shopper adjusts anything. And when a quantity change or a removal changes the total, the new total is never announced, only the original total from when the cart first opened. A screen reader user can change what's in their basket and never hear confirmation of what they now owe.
A pattern worth flagging: prices that are never announced
NVDA never announces product prices anywhere on this site, not on category listings, not on individual product pages. This is now a pattern we've seen across several of our audits, on sites otherwise unrelated to each other. It's a genuinely easy thing to miss, because the price is visually right there and looks completely normal, it just isn't being communicated to anyone using a screen reader. If you're a merchant and you haven't specifically checked for this, it's worth checking.
Everything else we found by hand
- Two "More info" buttons beside sensitive checkout fields, the phone number field and the card security code field, announce themselves as "expanded" once activated, but never actually read out the help content they're supposed to reveal.
- The expiry date field's "MM/YY" placeholder is read aloud by NVDA as "millimetre, YY," a small, almost funny-sounding failure that lands at exactly the worst moment: while someone is trying to complete a card payment.
The takeaway
What this means for a real client
The scan correctly found real, fixable issues, malformed lists, unlabelled links, low contrast, structural heading problems. All worth doing. None of it, though, would have told this retailer that their own navigation menu covers up the products on their site for keyboard users, or that their cart tells screen reader users it's empty right after they've added something to it.
Those two findings sit at opposite ends of the same problem. One is a menu that won't get out of the way; the other is a system actively telling a customer something false about their own basket. Neither shows up in code-level scanning, because both are about what happens when someone actually operates the site in sequence, not about whether individual elements are labelled correctly.
For a business in this retailer's position, the real-world effect is a checkout journey where a keyboard user can lose sight of the product they're buying, and a screen reader user can't trust what they're told is in their basket or what it costs. That's not a marginal accessibility gap, it's friction and misinformation sitting directly in the path of every sale. It's also exactly the kind of concrete, specific, reproducible barrier that EAA and Equality Act complaints are built from, precisely because it's so easy to demonstrate once someone tests for it properly.
This is why we run both checks on every audit, the scan for the fast, structural issues, and the manual pass for the ones that actually stop or mislead a paying customer.
Your site
Curious what we'd find on yours?
Start with a free automated scan to see the obvious issues first, or get in touch about a full manual audit of your checkout and login flows.