skip to content

What does the CSS order property change about a flex item's presentation, and what does it leave unchanged?

level: middleimportance: must knowfreq 56%

answer

  1. visual only, never structural
  2. the DOM is untouched
  3. keyboard focus still follows source order
  4. integer, default 0, negatives allowed
  5. meaningful sequence is the accessibility risk

basics

~20 s

order changes only the visual and paint sequence of flex or grid items inside their container. The DOM is untouched, so keyboard tab order, screen-reader reading order, and JavaScript traversal all still follow source order.

solid answer

~50 s

`order` takes an integer, defaults to `0`, and may be negative. Within a flex container the items are sorted by ascending `order`, with ties broken by source order — that sequence is called order-modified document order, and it drives both where items sit and the order in which they paint. What it does not do is move anything in the DOM: `document.querySelectorAll` still returns source order, sequential keyboard focus still walks source order, and assistive technology reads the accessibility tree, which comes from the DOM too. So `order: -1` on a button visually promotes it to the front while a keyboard user still tabs to it last. That mismatch is a real accessibility defect under WCAG's meaningful-sequence and focus-order criteria, so `order` is for cosmetic rearrangement of peers, not for putting content where it logically belongs — for that, change the markup.

code

html · 10 lines
html
<style>
  .toolbar { display: flex; gap: 8px; }
  .toolbar .save { order: -1; }
</style>

<div class="toolbar">
  <button>Cancel</button>
  <button>Duplicate</button>
  <button class="save">Save</button>
</div>

go deeper

for a junior

Know that order is an integer on a flex or grid item, defaults to 0, sorts ascending, and moves the item visually only. Say plainly that the HTML source order is unchanged.

for a middle

Explain order-modified document order, tie-breaking by source order, and that keyboard focus and screen readers follow the DOM instead. Mention that order also influences paint order.

for a senior

Show that you treat a visual-versus-DOM mismatch as an accessibility defect, name the meaningful-sequence and focus-order criteria, and reach for a markup change rather than a tabindex patch.

for a principal

Own the rule for the codebase: define where cosmetic reordering is acceptable, require a keyboard pass in review, and weigh the cost of restructuring markup per breakpoint against shipping a component that reads differently than it looks.

## What order actually does `order` is an item-level property that applies to flex items and grid items. Its value is an `<integer>`, its initial value is `0`, and negative values are allowed. Items in a flex container are laid out in **order-modified document order**: sort by the `order` value ascending, and where values tie, keep source order. Because `0` is the default, a single item set to `order: -1` jumps ahead of every untouched sibling, and `order: 1` falls behind them all — you rarely need to number every child. ```css .toolbar { display: flex; } .toolbar .primary { order: -1; } /* renders first, still last in the DOM */ ``` Two details are worth knowing precisely. First, in a wrapping container the ordering is applied *before* items are collected into flex lines, so `order` changes not just position within a line but which items share a line at all. Second, `order` also affects **painting order**: flex items paint as though they were in order-modified document order, which means a reordered item can overlap its siblings differently than the source order would suggest. One more boundary: `order` only has an effect on children of a flex or grid container. Set it on a block-level child of an ordinary block container and nothing happens. ## What order deliberately does not do This is where interviews focus, because the property is a well-known accessibility trap. - **The DOM does not move.** `element.nextElementSibling`, `querySelectorAll`, and serialization all reflect the markup you wrote. Nothing in the document tree changed. - **Sequential focus order does not move.** Tabbing walks the document in source order. A visually first button that is last in the DOM is the last thing a keyboard user reaches, which produces a focus ring that appears to leap backwards across the screen. - **Screen readers do not follow it.** Assistive technology reads the accessibility tree, which is built from the DOM. The announced sequence is source order, so a visual reader and a screen-reader user get two different stories. - **Text selection and copy/paste follow source order** too, so a user dragging across a reordered row can copy text in an order that does not match what they see. The W3C's own guidance is explicit that a mismatch between visual order and DOM order can fail WCAG 1.3.2 *Meaningful Sequence* (the reading order must be programmatically determinable when it affects meaning) and WCAG 2.4.3 *Focus Order* (focus order must preserve meaning and operability). The CSS Working Group has acknowledged the problem, and Chromium has begun shipping a `reading-flow` property that lets a container expose its visual order to focus and accessibility APIs. As of 2026 that is Chromium-only and not broadly available, so it is not something to rely on in production; treat visual reordering as still carrying its accessibility cost everywhere else. ## When order is fine, and when it is not It is fine when the reordered items are **peers with no meaningful sequence** — a row of equally weighted filter chips, a set of sibling cards whose reading order carries no argument, a media object whose image and text can be read in either order without confusion. It is fine when you are reordering *within* a small, focusable-neutral group where the source order is already sensible for a keyboard. It is not fine when it changes the meaning or the operable sequence: promoting a primary call-to-action ahead of the fields it submits, moving a heading below the content it labels, or shuffling a group of interactive controls so tabbing zig-zags. In those cases the correct fix is to change the markup and let CSS style whatever order the document already has. ## What not to reach for instead The tempting patch is positive `tabindex` values (`tabindex="1"`, `tabindex="2"`) to make focus follow the visuals. Don't: positive tabindex pulls those elements ahead of the entire rest of the page's focus order and is notoriously fragile to maintain. `flex-direction: row-reverse` or `column-reverse` reverses an entire container's visual order and carries exactly the same DOM-versus-focus mismatch, so it is not a loophole either — it is the same trade in a different spelling. ## How to spot the bug in review Tab through the component with the mouse untouched and watch the focus ring. If it jumps to a place your eye did not expect, the visual order and the DOM order have diverged. That single manual pass catches nearly every misuse of `order`.

  • If you set order: -1 on the third of three flex items, what does a keyboard user experience?
    They see that item rendered first, but tabbing still reaches it third, because sequential focus navigation walks the DOM. The focus ring appears to jump backwards across the row. Nothing in the CSS changed the document tree, so the visual and operable sequences have diverged — which is precisely the WCAG focus-order failure this property invites.
  • Is flex-direction: row-reverse a safer alternative to order for flipping two items?
    No, it is the same trade. row-reverse changes only the visual sequence of the container's items; the DOM, tab order, and accessibility tree are unchanged, so a reversed row still reads and focuses in source order. If the sequence carries meaning, reorder the markup instead and use CSS only for presentation.
  • Does order affect anything other than position, such as painting?
    Yes. Flex items paint as if they were in order-modified document order, so reordering can change which item ends up on top where boxes overlap. In a wrapping container, ordering is also applied before items are collected into flex lines, so order can change which items share a line.
  • Why not fix the mismatch with positive tabindex values?
    Positive tabindex hoists those elements ahead of every other focusable element on the page, not just their siblings, so it breaks the surrounding document's focus order and is very brittle as the page evolves. The maintainable fix is to put the elements in the DOM in the order they should be read and operated.

saying these in an interview costs you the question

  • Thinks order rearranges the DOM or the accessibility tree
  • Assumes screen readers announce items in visual order
  • Uses order to promote a primary action or a heading
  • Patches the resulting tab order with positive tabindex
  • Believes order works on ordinary block-level children

context

resolving links…