The Menubar That Refused to Choose

I was looking at easyJet's primary navigation and found something worth thinking about: this is a substantial mega menu, where richer keyboard interaction is genuinely useful, and the team has clearly invested in going beyond the minimum.

This post is not an accessibility review of easyJet, and should not be read as an endorsement or criticism of the site's overall conformance. I am using one ambitious component as a way to think about semantics, keyboard interaction, and the compromises that appear when we try to support more users rather than fewer.

And, before getting critical, a shoutout to the team for taking on the hard problem. Ambitious accessibility work is how we learn where the patterns help, where they constrain us, and where more pragmatic solutions may be worth testing.

Two APG approaches

The ARIA Authoring Practices Guide menubar pattern treats a menubar as a composite widget. Tab moves into or out of it; arrow keys move between menu items. The navigation menubar example follows that model with roving tabindex.

By contrast, APG's disclosure navigation example deliberately does not use menubar or menuitem roles. It keeps the native link and button semantics, preserves normal Tab and Shift+Tab navigation, and adds arrow keys as an optional enhancement. APG explicitly says the arrows supplement, but do not replace, tabbing.

That is a sensible distinction. A composite widget has a predictable keyboard model, and consistency matters.

But it also creates an interesting tension.

A nav landmark tells users what the region is: site navigation. A menubar tells assistive technology users something about how it behaves: expect menu-style interaction, including arrow keys. Those are different pieces of information, and both can be useful.

The easyJet component exposes the menubar interaction model, but not the navigation landmark. That matters because the two semantics frame different expectations. A screen-reader user who hears "menubar" and "menu item" has a clue that arrow-key interaction is available. A sighted keyboard user gets no equivalent announcement. They see site navigation, press Tab, and reasonably expect Tab to continue moving through it.

For a simple row of links, that may not matter much. For a large mega menu like easyJet's, arrow navigation can be genuinely useful.

Why not both?

The easyJet implementation appears to preserve ordinary Tab navigation while also supporting arrow-key navigation. That is not the canonical APG menubar model, but I find the motivation compelling:

Tab / Shift+Tab  → familiar sequential navigation
Arrow keys       → faster menu-style navigation

That redundancy can be a feature rather than a flaw.

APG already accepts this combination for ordinary disclosure navigation. The unresolved question is whether adding menubar semantics should force authors to remove the familiar Tab model simply to preserve the purity of the composite-widget convention.

A possible reconciliation would look roughly like this:

<nav aria-label="Site">
  <ul role="menubar">
    <li role="none">
      <a role="menuitem" href="/en/holidays">Holidays</a>
    </li>
  </ul>
</nav>

Keep the links tabbable. Add arrow navigation. Let nav describe the purpose of the region, and let menubar/menuitem communicate the richer interaction model to assistive technology.

I am not presenting that as a new pattern. I am saying it is a combination worth testing rather than rejecting automatically.

Ambition has a cost

Testing the real component made that qualification important.

With NVDA, the menubar and menu-item semantics are announced, but users can remain in browse mode, where arrow keys belong to the screen reader rather than the page. A user can switch to focus mode and access the richer interaction, but not every user will know or choose to do that.

None of that proves the ambition was misplaced. It demonstrates its price.

A sophisticated accessibility solution creates more interfaces between HTML, ARIA, JavaScript, browser focus, pointer behavior, and assistive technology. Every additional layer creates another place where a thoughtful idea can become fragile.

That is why I would still start with a resilient baseline:

native controls
logical focus order
Tab / Shift+Tab
reliable focus
clear navigation semantics

Then add the richer interaction without taking that baseline away. And, where arrow navigation is a deliberate and tested part of the experience, add menubar/menuitem semantics to inform AT users that the richer keyboard model is available.

Pragmatism over purity

APG is understandably conservative. Its patterns favor consistency: if something is exposed as a composite widget, it should behave like one. That predictability is valuable.

Authors have a slightly different responsibility. We are not designing specifications; we are designing experiences for people.

If menubar gives an AT user a useful hint that arrow navigation exists, and keeping links tabbable helps a sighted keyboard user without removing that richer interaction, I would rather test the combination than discard it solely for pattern purity.

The test is not whether the solution looks elegant in a pattern table. The test is whether it remains understandable, operable, and robust across the users and technologies it claims to support.

Universal design should not improve the experience of one group of keyboard users by making it worse for another.