Reading Order

Before you start

CSS can put anything anywhere. A screen reader does not look at where things are. It reads the HTML in the order it is written, and the Tab key visits controls in that same order. When a layout rearranges things with CSS, sighted readers see one sequence and everyone else gets another.

Below are six numbered steps in a grid. Each card has a label showing where it is seen and where it is read. Move them with the arrow buttons, with the arrow keys while a card has focus, or by dragging. Start in "Move with CSS" and watch the read positions refuse to follow.

What you just learned

• Two orders, one of them invisible. The visual order is where things are. The DOM order is where they are in the HTML. Screen readers, the Tab key, reader modes, search snippets, and copy-and-paste all use the DOM order.
• CSS order is the usual culprit. So are flex-direction: row-reverse, explicit grid placement, and absolute positioning. All of them move the pixels and leave the reading order where it was.
• The fix is to change the DOM. If a card should come first, put it first in the HTML. In "Move the DOM" mode every move does that, and the read positions follow instantly.
• The exception is content whose order does not matter. A row of equal cards can be reordered visually without harm. Numbered steps, headings, form fields, and navigation cannot.
• Tab is the quick test. If focus jumps backward or sideways as you press Tab, the two orders disagree. You do not need a screen reader to find this bug.

The field note Reading order is not visual order covers the CSS cases in detail, and corpus page 18-reading-order plants two of them for an agent to find.

Embed this lab

Host the Reading Order lab on your own page with one element and one script. It runs entirely in the visitor's browser, sends nothing back, and adds a small credit link.

<div data-a11y-world-lab="reading-order"></div>
<script src="https://a11y.world/embed.js" async></script>