A dashboard lays out six cards in a CSS grid and uses the order property so the most important card appears first on narrow screens while staying later in the HTML. Keyboard users tab through the cards in an order that does not match what they see. The page has about 40 focusable elements. Which change fixes this at the right level?

The mechanism

Sequential focus navigation follows document order, adjusted only by tabindex. CSS order, grid-area, flex-direction: row-reverse and absolute positioning change where a box is painted and change nothing about the order in which it is reached. Screen-reader reading order follows the same document order, so the mismatch is heard as well as felt.

Two WCAG success criteria describe this directly: 1.3.2 Meaningful Sequence, on programmatically determined reading order, and 2.4.3 Focus Order. WCAG 2.2 became a W3C Recommendation on 5 October 2023 and both criteria are inherited unchanged from 2.0, so this is not a new requirement.

Why the HTML is the right level

The source order is the single ordering that both keyboard and assistive technology use, and it is also the one a search crawler and a reader-mode extension use. Fixing it removes the divergence rather than papering over it, and it costs one markup change rather than a convention every future component must honour. Prefer moving the card in the markup when it must move for one breakpoint, and let CSS express layout rather than sequence.

Why the other options fail

• Positive tabindex promotes those elements ahead of every element with tabindex="0" on the page. With roughly 40 tab stops here, tabindex="1" on a card jumps to the front of the whole document, including the header and the skip link, and the next component to try the same trick fights with it. It is the standard remedy and it is wrong at a page level, which is why guidance has advised against positive values for years.
• aria-flowto describes a reading order to some assistive technology. Support is inconsistent, and it does not change keyboard focus order at all, so the keyboard user is unhelped and the two orders now disagree in a third way.
• A focus trap with arrow keys is the right pattern for a composite widget where a group of controls is one tab stop — a toolbar, a data grid, a tab list. Applied to six independent cards it adds a key-binding convention users have no reason to expect and hides the cards' contents behind a second interaction.

When this is the wrong answer

If the visual order genuinely differs per breakpoint and the markup cannot serve both, the fix is to render different markup per breakpoint on the server or to drop the reordering as a design requirement. A grid whose visual order matches the source at every breakpoint is the cheapest accessible layout there is, and reordering is a decision worth refusing early.

Common weak answers

• "Automated checks pass so it is fine." A tool can compare source order to focus order only when the intended order is declared somewhere, and here the intent exists only in the design. This class is found by a single tab-through, which is why that pass belongs in the release checklist.