webdevpuneet.com

Related Snippets

64 in Visualizers category
20–25 of 60

CSS reading-flow Demo

CSS text-box-trim Demo

CSS light-dark() Theme Demo

Live Region Announcer Demo

Canvas Conway's Game of Life

CSS backdrop-filter Playground

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

CSS reading-flow Demo · Visualizers · Plain HTML, CSS & JS · Live preview

CategoryVisualizers
TagsDrag & DropText EffectsAccessibilityCSS Grid

Copy & paste

Source Code

<div class="demo-wrap">
  <p class="demo-note">This grid's visual order is deliberately scrambled from its source order &mdash; card 3 is placed first on screen, card 1 last. Try pressing <kbd>Tab</kbd> from the button above the grid. With the new CSS <code>reading-flow</code> property, keyboard and screen-reader order follows the sensible visual order instead of the confusing raw source order.</p>

  <button class="focus-anchor" id="focusAnchor">Tab from here &rarr;</button>

  <div class="flow-grid" id="flowGrid">
    <a class="flow-card order-3" href="#" tabindex="0"><span class="badge">3rd in source</span><h3>Reviewed</h3></a>
    <a class="flow-card order-1" href="#" tabindex="0"><span class="badge">1st in source</span><h3>Submitted</h3></a>
    <a class="flow-card order-4" href="#" tabindex="0"><span class="badge">4th in source</span><h3>Shipped</h3></a>
    <a class="flow-card order-2" href="#" tabindex="0"><span class="badge">2nd in source</span><h3>Approved</h3></a>
  </div>

  <div class="fallback-note">
    <strong>Support note:</strong> <code>reading-flow</code> is a very new, experimental CSS property. Where it isn't supported, Tab order simply follows plain DOM source order &mdash; usable, but it won't match the visual left-to-right order shown above.
  </div>
</div>

Extend with AI

Take This Snippet Further With AI

The AI prompt for this one is for Patreon supporters ($3 a month, 7 days free), along with a site with no ads. Supporters enter the passcode once and it is remembered in this browser.

· Become a supporter

What's included

Features

Deliberately scrambled visual order
Grid placement intentionally differs from DOM source order.
reading-flow: grid-order
Aligns tab order and reading order to visual position, not markup order.
Targets a real, common bug class
Grid/flex visual reordering breaking keyboard navigation.
No tabindex > 0 hacks
Avoids the widely discouraged manual-tab-order anti-pattern.
Graceful, honest fallback
Unsupporting browsers just use plain DOM order — still usable.
Visible source-order badges
Each card labels its real DOM position for easy comparison.
Zero JavaScript
A pure CSS property with no script-side detection needed.
Pairs with responsive reflow
Useful anywhere breakpoints change visual order per screen size.

About this UI Snippet

CSS reading-flow Demo — Keeping Tab Order Sane When Visual Order Isn't Source Order

Screenshot of the CSS reading-flow Demo snippet rendered live

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.

Step by step

How to Use

  1. 1
    Read the badges on each cardThey show each card's real DOM source order (1st through 4th), independent of screen position.
  2. 2
    Click "Tab from here"This focuses a starting point right above the grid.
  3. 3
    Press Tab repeatedlyIn a browser supporting reading-flow, focus moves in visual reading order (top-left, top-right, bottom-left, bottom-right).
  4. 4
    Compare to a browser without supportTab order there follows plain DOM source order — 1st, 2nd, 3rd, 4th — which won't match the visual grid.
  5. 5
    Inspect the grid-column/grid-row placementSee how visual order is scrambled independent of the HTML's own element order.
  6. 6
    Check the @supports (reading-flow: grid-order) blockThe only place reading-flow is actually applied.

Real-world uses

Common Use Cases

Dashboard and card grids
Keep Tab order sensible when cards are visually rearranged, using reading-flow: grid-order to follow visual position.
Responsive reordering
Handle layouts that reorder per breakpoint, where keyboard and screen reader order would otherwise follow the DOM and confuse users.
Masonry-style galleries
Pair with the native CSS masonry gallery, since packed columns often scramble the order a keyboard user experiences.
Accessibility audits
Demonstrate and test the mismatch between visual and source order, without resorting to the discouraged positive tabindex hack.
Keyboard navigation toolkits
Combine with a focus visible demo and a skip to content link for a more complete keyboard experience.
Related: Two-Column FAQ
See the Two-Column FAQ for a related layouts pattern worth pairing with this one.

Got questions?

Frequently Asked Questions

Keyboard tab order and screen-reader reading order have traditionally followed raw DOM source order, regardless of how CSS visually repositions elements with grid-column/grid-row, flexbox order, or absolute positioning. This mismatch is a long-standing accessibility bug class: a layout can look perfectly ordered on screen while a keyboard user tabbing through it jumps around according to the markup instead of what they see.

Set on a grid container, it 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 navigating through the grid follows the sensible on-screen order even when that differs from how the elements are written in the markup.

Very early, as of 2026 — this is one of the newest and least-settled properties covered in this collection, with only limited implementation across browser engines and an evolving specification. Treat it as genuinely experimental and verify current support in your specific target browsers before depending on it.

No meaningful one. Without reading-flow, the browser falls back to plain DOM source order for Tab and screen-reader navigation — a fully usable but not visually-matched order. The honest fallback approach is to write your DOM in the order you want things read and tabbed through, applying CSS purely for the visual rearrangement on top, rather than trying to fake reading-flow's exact behavior another way.

Setting explicit positive tabindex values to force a specific tab sequence is widely considered an anti-pattern in accessibility guidance: it creates a separate, hard-to-maintain order that has to be manually kept in sync with any layout change, and it interacts confusingly with the rest of the page's natural (zero/unset) tabindex elements, often producing a worse and more surprising experience than the DOM-order mismatch it was meant to fix.