CSS reading-flow Demo — Free Experimental Visual/Tab Order Sync

CSS has always let you rearrange elements visually without touching the DOM — grid-column/grid-row placement, order in flexbox, absolute positioning — but keyboard tab order and screen-reader reading order have traditionally followed raw DOM source order regardless of how the page actually looks. That mismatch is a well-known, persistent accessibility bug class: a grid can look perfectly ordered left-to-right on screen while a keyboard user tabbing through it jumps around unpredictably, because Tab is following the markup, not the layout. reading-flow is a new CSS property, part of the CSS Overflow/Display specifications' ongoing work, aimed directly at that gap.

What's scrambled in this demo, on purpose

The four cards in #flowGrid are written to the DOM in one order (Reviewed, Submitted, Shipped, Approved) but visually placed in a different order using explicit grid-column/grid-row values, so "Submitted" (1st in source) actually appears top-right on screen while "Reviewed" (3rd in source) appears top-left. This exact pattern — CSS Grid or Flexbox visually reordering content away from its source order — is extremely common in real layouts (responsive reflows, masonry-style card grids, dashboard widgets) and is exactly the situation where DOM-order-based tab sequences stop matching what a sighted user sees.

What reading-flow: grid-order actually changes

Setting reading-flow: grid-order on the grid container tells the browser to derive both keyboard tab order and the accessibility tree's reading order from the grid items' actual visual position, rather than their DOM source position — so tabbing through this scrambled grid follows the sane top-left-to-bottom-right sequence you see on screen, matching how a sighted user would naturally scan it, instead of jumping according to source order. This directly targets a category of bug that used to require either reordering markup to match every possible visual arrangement (impossible once responsive breakpoints reorder things differently at different widths) or resorting to tabindex values greater than zero, a technique widely considered a genuine anti-pattern because it creates its own, different order-mismatch problems and is broadly discouraged in accessibility guidance.

Very new — treat this as genuinely experimental

Be honest with yourself about where this property stands: as of 2026, reading-flow has only limited and early implementation support across browser engines, and the specification itself is still evolving. This is meaningfully newer and less settled than most other properties in this batch of snippets. There's no meaningful CSS-only fallback for its actual behavior — this snippet's @supports block simply omits the property where unsupported, and the browser falls back to plain DOM source order for Tab and screen-reader navigation, which stays fully usable but won't match the scrambled visual arrangement above.

The honest workaround today

Until reading-flow has broad support, the only reliable way to keep tab order aligned with visual order is to write your DOM in the order you want things read and tabbed through, and use CSS purely for the *visual* rearrangement layered on top — never reach for tabindex greater than zero to force a different order, since it's widely discouraged and tends to create worse, harder-to-reason-about inconsistencies than the problem it's solving. Pair this with the focus-visible explainer and the skip-to-content link as part of a broader keyboard-navigation accessibility toolkit.