The business: a UK independent skincare and beauty retailer selling online, with a typical ecommerce setup: product catalogue, cart, and checkout with a choice of card or PayPal.
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.
What a scanner found in seconds
The automated scan returned:
- Serious (2): text with insufficient colour contrast against its background (7 instances), and one link with no text a screen reader can announce.
- Moderate (1): content sitting outside any landmark region.
- Minor (1): alt text duplicating visible text (11 instances).
Nothing here is nothing: contrast issues and unlabelled links are real barriers and worth fixing. But taken at face value, this is a site with zero critical issues and a short, fixable list. If this were the whole picture, it would look like a low-risk site.
It isn't the whole picture.
What only manual testing found
Testing the site by hand, tabbing through every interactive element and listening to it with NVDA, surfaced a second, more serious layer that the scan didn't touch at all.
The headline finding: PayPal was invisible to keyboard users
At checkout, two payment options are shown: credit card and PayPal, one above the other. Card is pre-selected and fully usable by keyboard: tab to it, arrow between options, done. PayPal isn't reachable at all. Tabbing through the payment section skips straight past it. No keyboard-only user, someone with a motor impairment who can't use a mouse, or a screen reader user navigating the same way, can select it. Visually it sits there like any normal option; nothing on screen suggests it's dead.
This is a blocker, not a minor inconvenience: a customer who wants to pay by PayPal, and can't use a mouse, cannot complete the purchase. Full stop. And it didn't appear anywhere in the automated scan, at any severity level, because a scanner checks whether an element has the right role and label in the code. It doesn't actually try to tab to it and use it the way a real customer would. That gap is exactly where this issue was hiding.
The second finding: removing an item from the cart happens silently
Clicking "Remove" on a cart item takes it off the list, but NVDA announces nothing when it happens. A sighted user sees the item disappear and the total update; a screen reader user gets no confirmation the action worked and no announcement of what changed. They're left to manually re-check the whole cart to find out if anything happened. This is a WCAG requirement around communicating status changes to assistive technology, not just displaying them, and again, it's invisible to an automated scan, which has no way to know an action was supposed to produce an announcement in the first place.
Everything else we found by hand:
- A floating rewards button only reachable at the very end of the tab order, with a broken focus indicator and overlapping icon/text on focus.
- Keyboard focus visually misaligning with on-screen position while tabbing through the homepage.
- A cookie consent popup that ignores the Escape key and must be dismissed by tabbing to a button manually.
- A shipping banner read out of visual order by NVDA.
- Category pages requiring a full pass through every header dropdown before reaching the product listing, with no way to skip ahead.
None of these alone stop a sale. Together, they add friction at nearly every stage of the same journey.
What this means for a real client
The automated scan wasn't wrong: it correctly found real issues. It just couldn't see the ones that mattered most. A scanner reads code structure: is there a label, is there a role, is contrast within range. It cannot tab through a checkout and try to actually choose PayPal. It cannot listen to a page with a screen reader and notice that nothing gets announced. Those are the two issues on this site with the clearest, most direct business impact: one removes a payment method entirely, and the other undermines trust in whether the cart is working at all. Both sat completely outside the scan's zero-critical result.
For a business in this retailer's position, that's the real risk of stopping at an automated scan: a "clean-looking" report that misses the exact failures a customer would actually hit trying to buy something, and the exact failures that EAA and Equality Act complaints are built on. It's also why we always run both: the scan is fast and useful for the surface-level issues, but it's the manual pass, on every single audit, that catches the ones that actually cost a sale.
Curious what a full manual audit would find on your own site? Get in touch, or start with a free automated scan to see the obvious issues first.