Reading order & meaningful sequence

Flexbox and grid let you place a box anywhere on screen regardless of where it sits in the markup — with the order property, row-reverse/column-reverse, or explicit grid-row/grid-column placement. None of that changes the DOM. A screen reader still reads, and the Tab key still moves, in source order. So if the source says “price, then description, then Buy” but CSS paints “Buy, then price”, a sighted user and a screen reader user are handed two different stories. When the sequence carries meaning — steps, a question before its options, a control after the thing it acts on — that mismatch is a 1.3.2 failure.

<div style="display:flex; flex-direction:column">
  <button>Delete account</button>          <!-- DOM 1st -->
  <p style="order:-1">This cannot be undone.</p> <!-- painted 1st -->
</div>
<!-- Eyes: warning then button. Screen reader: button then warning. -->

<div style="display:flex; flex-direction:column">
  <p>This cannot be undone.</p>
  <button>Delete account</button>
</div>
<!-- One order for everyone. -->

/* Safe: equal, independent cards rearranged for layout only. */
@media (min-width: 60rem) {
  .feature--promoted { order: -1; } /* still reads fine in any order */
}

/* Risky: never use order to move a control away from the
   content it relates to, or a step out of its sequence. */

By default the browser walks focusable elements in DOM order — a tab order you mostly get for free. Any tabindex greater than zero opts out of that. The browser first visits every element with a positive value, in ascending number order, and only then falls back to DOM order for the rest. So a single tabindex="1" on one button can yank focus to it ahead of everything above it, and a handful of stray positive values produce a focus path that jumps around the page unpredictably. It’s brittle, too: insert a new field and the hand-numbered sequence is wrong again. This breaks 2.4.3 because the focus order no longer preserves meaning or operability.

<input id="name" tabindex="3">
<input id="email" tabindex="2">
<button tabindex="1">Submit</button>
<!-- Tab order: Submit → email → name. Backwards. -->

<input id="name">
<input id="email">
<button>Submit</button>
<!-- Tab order follows the DOM: name → email → Submit. -->

<!-- 0: custom control joins the tab order in DOM position -->
<div role="button" tabindex="0">Toggle</div>

<!-- -1: focusable by script only, not via Tab -->
<div role="dialog" tabindex="-1" id="dialog">…</div>
<!-- dialog.focus() when it opens -->

<!-- Never: tabindex="1" or any positive value -->

Hiding is part of reading order: anything removed from the accessibility tree simply isn’t in the screen reader’s sequence. The four common techniques hide from different audiences, and mixing them up either leaks content that should be gone or strips content that should stay. display:none and the hidden attribute remove an element from everyone — layout and the accessibility tree alike. A visually-hidden (or “sr-only”) class hides it visually but keeps it for screen readers — ideal for a label or skip link. aria-hidden="true" does the opposite: it stays on screen but vanishes from assistive tech. The two classic mistakes are using display:none on text that screen reader users need, and putting aria-hidden="true" on (or around) something focusable — which leaves keyboard users tabbing to a control that announces nothing.

<!-- A: label hidden from screen readers, button left nameless -->
<button aria-hidden="true">&times;</button>

<!-- B: instruction removed from everyone, but SR users need it -->
<p style="display:none">Format: DD/MM/YYYY</p>

<!-- A: glyph decorative, real name on the button -->
<button aria-label="Close"><span aria-hidden="true">&times;</span></button>

<!-- B: hint kept for screen readers, hidden from sight -->
<p class="visually-hidden">Format: DD/MM/YYYY</p>

.visually-hidden {
  position: absolute;
  width: 1px; height: 1px;
  padding: 0; margin: -1px;
  overflow: hidden;
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  white-space: nowrap;
  border: 0;
}