Monitoring Focus Order After a Mega-Menu Rebuild

November 6, 2026

A rebuilt mega-menu usually changes the DOM order, and focus order follows the DOM. Keyboard users end up tabbing through the footer before the nav.

A store rebuilds its mega-menu with a new framework. The menu looks identical, the links are the same, and the mouse experience is untouched. A keyboard user tabs through the header and lands on the newsletter signup in the footer, then the checkout button, then back up to the menu, because the new DOM order puts the menu markup after the page content and positions it visually with CSS.

Focus order follows the DOM, not the screen. That is the rule, and it is also the reason mega-menu rebuilds are one of the most reliable sources of keyboard regressions on a storefront. The visual layout lies; the tab order tells the truth.

Why the rebuild breaks it

The old menu was markup in order: header, nav, content. The new one is built by a component library that renders the menu panel at the end of the document and pulls it into place with absolute positioning. Sighted users see the same menu. Keyboard users get the document order, which now runs header, content, footer, and finally the menu. Screen reader users get the same broken sequence, because their reading order follows the DOM too.

Positive tabindex values make it worse. A developer who sets tabindex to 1, 2, 3 on the menu links to force them early creates a tab order that no longer matches anything, and the first tab stop after the menu jumps somewhere unrelated. Positive tabindex is almost always a mistake, and in a rebuilt menu it is a reliable sign the team fought the DOM instead of fixing it.

A check that runs in minutes

After any navigation rebuild, tab through the header without a mouse and write down the order of stops. The sequence should be: skip link, logo, search, account, cart, then the menu items in the order they appear on screen, then the page content. If the menu comes after the content, the DOM order is wrong, and no amount of tabindex patching fixes it cleanly.

Add the same check to the release process. A simple automated test that tabs through the first twenty stops and compares them to an expected list catches the regression the day it ships. The test is cheap because the expected list rarely changes.

The repair

Move the menu markup to where it appears visually, before the main content, and let the DOM order do the work. Keep tabindex at zero or unset on menu links, and use roving tabindex inside the menu itself, with arrow keys moving between items and Tab leaving the menu. That is the pattern the W3C ARIA practices guide describes, and it is the one screen reader users already know.

If the framework cannot render the menu in place, render it in place anyway. A portal that mounts the menu at the end of the body for positioning convenience is trading a keyboard regression for a CSS convenience, and the trade is never worth it.

Frequently asked questions

Does focus order follow the screen layout or the code?

It follows the DOM order, the order elements appear in the code. CSS can move things visually, but Tab and screen reader reading order both use the document order, so a menu positioned with CSS but written at the end of the page tabs last.

Is positive tabindex a fix for focus order?

No. Positive tabindex values create a tab sequence that matches nothing on screen and breaks as soon as the page changes. Keep tabindex at zero or unset, and fix the DOM order instead.

How do I test focus order after a menu rebuild?

Tab through the header without a mouse and write down the stops in order. The sequence should match the visual layout: skip link, logo, search, account, cart, menu items, then page content. Any menu item that comes after page content is a defect.

What is roving tabindex in a menu?

A pattern where one menu item has tabindex zero and the rest have tabindex minus one, with arrow keys moving focus between items and Tab leaving the menu. It keeps the menu to a single tab stop while preserving keyboard access to every item.

Frequently asked questions

What is the main takeaway from An accessibility checklist before holiday traffic?

The main takeaway is to work through the basics in order, check each step as a real user would experience it, and fix patterns at their source rather than patching a single example. A short written record of what you checked makes the next review faster and more reliable.

How should I apply this guide in practice?

Pick one page, product, or routine and apply the steps there first. Note what changes, keep the change if the result improves, and only then roll the same pattern wider. Small verified changes beat a large unverified overhaul every time.

What should I check again later?

Recheck after any template, product, app, or routine change, and on a regular monthly rhythm in between. Conditions drift over time, so a dated check is what tells you whether a fix held or quietly broke again.