Linearization: Why Visual Reordering Breaks Reading and Focus Order

An interface has at least four orders, and they are supposed to be the same order.

The document order is the sequence of elements in the markup. The visual order is where those elements land on the screen after layout. The reading order is the sequence in which a screen reader or a text-to-speech engine traverses the content. The focus order is the sequence in which the Tab key moves between interactive controls. For a simple top-to-bottom layout all four coincide, and the designer never thinks about them. For any layout that reorders content, they diverge, and the divergence is invisible to anyone testing with a mouse.

Which order each consumer follows

The reading order is not a separate structure. A screen reader traverses the accessibility tree, which is built from the DOM in document order, with some elements flattened, some grouped, and some hidden. The browser’s accessibility tree preserves document order among siblings; grouping changes depth, not sequence. So the reading order is the document order, minus anything removed from the tree, plus any structure imposed by roles.

The focus order is the document order of focusable elements, with three modifications. Elements with a positive tabindex come first, ordered by the value of the attribute, then elements with tabindex="0" and natively focusable elements in document order. Elements with tabindex="-1" are focusable programmatically but not by Tab. This is the entire default algorithm, and it is defined in the HTML standard rather than by any user agent’s discretion, which means it is predictable.

The visual order is whatever the layout engine produces. Block flow follows document order, but several CSS features reorder painting and positioning without touching the DOM: order in flexbox and grid, grid-auto-flow: dense and explicit grid placement, position: absolute with coordinates, direction for right-to-left layouts, and transforms that move an element visually while leaving its layout box in place.

The divergence that matters is between the visual order and the other three. A sighted keyboard user tabs in one sequence and looks at another; a screen reader user hears content in an order that does not match what a sighted colleague describes. Both are disorienting, and both are caused by the same thing: the layout was designed as a picture rather than as a sequence.

The reordering case that is safe

Not all visual reordering is a defect. The distinction is whether the visual order remains a meaningful sequence, meaning whether the content still makes sense in document order, and whether the interactive elements in the reordered region are focusable at all.

Reordering purely decorative or non-interactive content is usually harmless. A layout that displays a caption above an image while the DOM places the caption after it changes nothing for a screen reader if the caption reads correctly in either position. Reordering static text whose meaning does not depend on adjacency is likewise benign, though it can still surprise a sighted keyboard user who is tracking a reading position.

Reordering interactive controls is where the cost lands. A toolbar whose buttons are placed with flexbox order so that the primary action appears first visually will still be traversed in DOM order, so a keyboard user reaches the secondary actions first. The visual cue, that the primary action is at the left where the eye starts, actively misleads. This is the single most common manifestation of the problem, and it is why the recommendation is to order the DOM to match the intended sequence and use layout to place it, rather than to order the DOM arbitrarily and use layout to fix it.

/* DOM order: skip, previous, next, submit.
   Visual order matches, so the two agree. */
.toolbar { display: flex; gap: 8px; }

/* If the design needs submit on the far right, move it with
   margin rather than with order: the DOM sequence is preserved. */
.toolbar .submit { margin-inline-start: auto; }

The margin-inline-start: auto technique is the general answer to “this control should be pushed to the far edge”. It changes position without changing sequence, so the four orders stay aligned. Logical properties are used rather than physical ones because the same declaration then works in a right-to-left layout, where the far edge is on the other side.

Absolute positioning and the reading order

Absolutely positioned elements are removed from normal flow, so their position is determined by their offsets while their place in document order is unchanged. A modal, a tooltip, a floating panel, and a decorative overlay are all implemented this way, and each has a different implication.

A modal dialog is the case where the visual order legitimately differs from the document order and where the divergence must be managed explicitly rather than eliminated. The dialog is usually placed at the end of the document so that it is not inside a container that might clip it, which means it appears last in document order but visually on top of everything. The management mechanism is focus: when the dialog opens, focus moves into it, and while it is open the rest of the document is made inert so that the focus order contains only the dialog. The reading order is handled by the same mechanism, since the accessibility tree of inert content is excluded. Without the inerting, a screen reader user can traverse the page behind the dialog, which is the classic modal defect.

A tooltip or popover that is positioned absolutely and appended at the end of the document has no such management, and the consequence is that its content is read at the end of the page rather than adjacent to its trigger. If the content is supplementary, that may be acceptable; if it carries a field’s instructions, it is not. The fix is to place it in the DOM next to the trigger and position it with CSS, or to associate it explicitly so that the reading order is not the only path to it.

Decorative overlays are the easy case: mark them as such and remove them from the tree. An element that is purely visual should not exist for the reading order at all, and an overlay that covers the content while remaining in the tree is worse than a visual nuisance, since it interposes itself between the reader and the text underneath.

Direction and the mirror-image layout

Right-to-left layout is not a transform applied to a left-to-right design. The dir attribute changes the base direction of the text and the inline base direction of the layout, which flips the start and end edges of everything expressed in logical properties. A layout built with margin-left and padding-right does not flip; a layout built with margin-inline-start does.

The reading order, however, does not flip. Document order is still document order, and a screen reader reads the content in that order regardless of the visual direction. For a correctly authored right-to-left page the two agree, because the content was authored in reading order for that language. The defect appears when a left-to-right layout is mirrored with CSS rather than authored for the language: the visual order reverses and the reading order does not, so a two-column layout with the sidebar on the start side will have its sidebar visually first and its content read first.

The bidirectional text algorithm adds a further wrinkle that is genuinely hard to reason about. When a paragraph mixes right-to-left and left-to-right runs, such as an Arabic sentence containing a Latin product name or a Hebrew sentence containing a number, the displayed order of the runs is determined by the Unicode Bidirectional Algorithm, which assigns each character a directionality class and resolves the ordering with an explicit embedding stack. A string whose visual order is correct can be read in a different order by a screen reader if the base direction is not set, because the reader follows the logical order of the underlying characters while the display follows the resolved visual order. Setting the base direction on the container is the constraint; leaving it to the first strong character in the content is a guess that fails on strings that begin with a number or a neutral character.

Keeping the four orders aligned

The constraint that prevents most of these defects is stated simply and is hard to satisfy only when it is applied late: author the DOM in the intended reading and focus sequence, then use layout to place content visually. This makes document order the single source of truth and reduces the problem from four orders to one.

Three practices follow from it.

Order the markup first, in a semantic sequence that a person reading the raw HTML would find coherent. A navigation landmark before the main content, a heading before the content it introduces, the fields of a form in the order a person would fill them.

Use layout mechanisms that place without reordering. Margin auto-placement, grid areas assigned by name, and logical properties all change position while preserving sequence. Reserve order and grid-auto-flow: dense for content that is genuinely order-independent, and treat their use on interactive content as a defect to be justified.

Manage the divergences that cannot be removed. Modal focus containment, roving tabindex in composite widgets, and skip links all exist because some visual arrangement cannot be expressed as a document sequence. Each of them is an explicit mechanism rather than an accident of layout, and each has a defined behaviour that can be tested.

The last point is why the constraint belongs in the design system rather than in review. A component that ships with an order-based layout will be used, and the defect will be reproduced everywhere the component appears. A component whose layout is sequence-preserving cannot reproduce it, which is the general argument for encoding constraints at the component definition. The relationship between sequence and layout also determines how a page survives a change in viewport: a layout that only makes sense at one width will reorder when the columns collapse, and a sequence-preserving implementation reflows without changing what is read. That collapse is the same event as magnification reflow, reached by a different route: zoom narrows the viewport in CSS pixels, and a breakpoint narrows it by media query, but both force the wide arrangement into a column and both expose whatever order the markup was authored in.