Tab order
The path the Tab key walks through a page's controls. It follows DOM order, not the order things appear on screen.
See it
What it is
Tab walks forward through a page's tab stops, Shift+Tab walks back. Not every focusable element is one of those stops: anything carrying tabindex='-1' can still be focused by script, it is just skipped by Tab. The sequence comes from the DOM, not from what you see: the browser reads source order, then applies any tabindex values on top.
That is why CSS breaks it. Flexbox order, grid placement, and absolute positioning move boxes on screen without touching the DOM, so focus can hop from the header to a footer link to something back up top. Fix it by reordering the markup, not by patching tabindex.
Gotcha: positive tabindex is a trap. tabindex='3' does not mean 'third'. It yanks the element ahead of every natural tab stop on the page, and a single stray positive value scrambles the whole document. Use tabindex='0' to add a custom widget to the natural order and tabindex='-1' to make something focusable by script only. Second gotcha: a toolbar, menu, or tab list should be one tab stop with arrow keys moving inside it (the roving tabindex pattern), not twenty stops the user has to Tab past.
Ask AI for it
Check the tab order of this layout against its visual and reading order. First list every tab stop in sequence next to where it sits on screen, so all three orders are visible side by side. Then fix only the places where they actually conflict: reorder the DOM there rather than patching tabindex, and leave layout CSS (flex order, grid placement, absolute positioning) alone wherever the logical order already reads correctly, since ripping it out can wreck a layout that was fine. Delete every positive tabindex value; use tabindex='0' only to make a custom interactive widget focusable and tabindex='-1' only for elements focused by script, remembering those are skipped by Tab. Collapse toolbars, tab lists, and menus into a single tab stop with arrow-key navigation inside.