The checkout blocker that excluded keyboard users from paying by PayPal

Industry

UK independent skincare & beauty retailer, online only

What we tested

Homepage, a category listing page, a product page, cart, and checkout

Testing method

Automated scan first, then manual keyboard-only navigation and NVDA, a free screen reader commonly used for UK compliance testing

The challenge

Like most ecommerce sites selling into the EU, this retailer needed to know whether its checkout actually works under the EAA's WCAG 2.2 AA standard, not just whether it looks fine and passes a quick automated check. A clean-looking scan can hide the exact failures a paying customer would actually hit.

The solution: automated scan, then manual testing

We ran an automated scan first, the same free type of check anyone can run in seconds.

• 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. We then tested by hand: tabbing through every interactive element and listening to the site with NVDA.

The result: what only manual testing found

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.

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. 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.

Everything else 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.

Show 3 more findings from this audit

• 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. The scan wasn't wrong, it correctly found real issues. It just couldn't see the ones with the clearest business impact: one removes a payment method entirely, and the other undermines trust in whether the cart is working at all.