Does this menu work with keyboard? The surprising number of big brands that fail

One of the simplest accessibility checks when landing on a website is to Tab through and see if the website works with keyboard. Let’s look at some major brands and see which ones pass this simple test just for their main menu.

Why does it need to work with keyboard?

Not all people navigate with mouse, many people need to use keyboard. WCAG 2.4.3: Focus Order (Level A), WCAG 2.4.7: Focus Visible (Level AA) applies in this context (for this post).

Method

We’re going to keep this simple, does the main navigation menu:

  1. Work with the keyboard Tab correctly as the order expected 
  2. Have visible focus styles (ideally that are consistent)

Open in a browser, start at the top and Tab my way through. I’ve added the keyboard presses to the video so we can see what key was being pressed.

That’s it for this test. We’re not going to even open the code or open a screenreader. We’re not going to navigate through the sub-menus. Each video opens up the brands homepage and then, using the keyboard, navigates through the menu.

We’re checking if they keyboard works in a logical order and the focus styles visible (and ideally consistent).

Gymshark

A complete mess. Jumps all over the place, wrong styles, has this big white block that appears out of no where. Fails everywhere.

Ocardo

Works great! This is what is expected, logical order and clear visible focus style.

Tesco

The focus styles are strange on the top menu. It looks like the hover styles were used, also as you move through the bottom menu the top border gets cut-off but certainly it works better than Gymshark.

ASOS

Pretty good, what I expected. It moves through in a logical order, the focus styles are visible.

Next

The focus gets lost, what’s going on here? Turns out it was getting stuck in this random marquee. I added a red focus style to see what was happening. Not good.

Currys

OK in terms of focus order, but the hover styles are being used instead of consistent focus. Some visual jumping as we land on menu items. Opening the search “screen” has a dimming overlay but the next Tab easily moves on.

John Lewis

Started well but then focus on the search opens this huge mega menu and forces me to navigate backwards or Esc to get out of it. I would be marking this as a WCAG fail. I would expect this open on interaction.

Example of a Failure: As a keyboard user tabs through the web page, the dialog opens, moving the keyboard focus away from the control every time the user attempts to tab past the field.

Alo

It seem to open the menu, like it was the hover state not the focus state which is unexpected, also the focus bottom border gets cut off.

Argos

The focus style gets visually lost on some items, like the search due the Design choice but functionality works well.

Boden 

Nothing. No focus style at all. Mess, fails everywhere.

Halfords

I have to close the search menu to continue which is a fail similar interaction to John Lewis, there is also visual jumping but the rest of the menu is OK.

eBay

I had to check what was happening here, it’s a strange focus order. It seems to loop in a really unexpected way.

Nespresso

It lands on the first item fine and then fails as the focus jumps elsewhere1

Bloom and wild

Some of the focus styling gets cut off and it visually jumps around which is jarring, but order wise works Ok in this test.

Gusto

Looks like there’s no skip link on this one but order and focus styles are Ok.

Synthesia

AI startup, the focus styles go missing completely the user can’t see where they are at all. Fails on both.

Takeaway

I really wanted to highlight how low the bar is for this type thing. While a couple work as-expected the vast majority have issues.

If industry-leading brands with entire design and engineering departments are letting basic bugs like this hit production, we have a real standard-of-quality problem. The quiet, pervasive devaluation of frontend speaks to some of the reasons to why this is happening. When only 5% of Frontend jobs mention WCAG, we have an issue.

Projects managers, QA all need to ensure work has acceptance criteria and this work is being actioned. Teams need dedicated Frontend and Accessibility specialists, interviews need to ask about WCAG. Otherwise, even the main menu on the homepage won’t work with keyboard properly, excluding users that rely on navigation this way.


  1. Disclaimer, ex-client this was raised in ’25 in detail but it looks the relevant team still have not fixed this unfortunately ↩︎

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *