Structural order is the order assistive technology walks

What it is

Assistive technology walks structural order: the sequence of nodes in the document tree and the accessibility tree is the sequence a screen reader reads linearly and the default Tab order follows. CSS that slides a sidebar visually to the right, absolute positioning that tucks a button into a card corner, order that paints “Next” first — those move pixels. They often do not move the tree. Top-to-bottom on screen need not be first-to-last for AT.

The implementation constraint is: to change traversal, change the tree. Layout-only changes leave traversal still. A visual reading path can be argued separately; the assistive channel does not automatically follow flex and grid placement.

Why it happens

Screen readers and default tab order consume the accessibility tree, which is generated mainly from source structure. Positioning, floats, grid placement, and flex order change painting; in most cases they do not rewrite sequence in the tree. Two orders then exist: eyes follow paint, AT follows source. Source that writes the sidebar before the article still hears the sidebar first even when the article is painted first; source that puts Cancel before Confirm still tabs to Cancel first even when Confirm is painted on the left.

Handing sequence to the paint layer ties the assistive channel to coordinates it does not read. Aligning the two channels means making source sequence equal the sequence you want read and tabbed. Visual rearrangement is an extra paint instruction, not a traversal instruction.

Where it stops holding

A deliberate mismatch (desktop paints navigation on the left, source places it after the article so the body is read first) can be valid if it is a written choice and checked on the assistive channel — “it looks left” is not evidence it is read first. tabindex greater than 0 pulls keyboard order out of source order and splits Tab from linear AT reading; that split cannot be used as a fix for visual order. Shadow DOM, display: contents, and engines that disagree about whether flex order affects Tab mean paint must not be assumed to leak into the tree across browsers. Spatial navigation in some screen readers (jump by on-screen coordinates) is not the default linear walk and does not prove implementation already follows visual order.

Applying it

• Deliver source order with the visual board: what is read first, where the primary action sits in the tree relative to cancel and secondary actions.
• Do not use flex order, negative margin, or absolute positioning to “move the primary action forward” without moving it in source.
• For columns, sidebars, and sticky bars, write the tree in the order that should be heard, then paint those nodes to their visual slots.
• How to check: disable CSS or open an accessibility-tree viewer and list node sequence; then linear-read with a screen reader and walk with Tab. The three sequences should match the declared traversal. Each mismatch is paint-only.

Related

• Same group: R3.01.1 Native semantic elements bring assistive-technology behavior with them · R3.01.2 Faking a control with a generic box requires filling in all of its semantics
• Nearby: J2.08 Reading order · R3.09 Semantic structure and accessibility implementation
• Search terms: DOM order · AT traversal · source order versus CSS order