Multi-column layouts need an explicit reading path
Aliases: column versus row order · column reading path · grid traversal
What it is
A two-column news page looks as if you finish the left column, then the right. If the source interleaves by row — left paragraph one, right paragraph one, left paragraph two — a screen reader will chew both articles into each other. Card grids, side-by-side plans, magazine-style CSS columns all have a path that ought to be walked: column-then-column, or row-then-row. That path has to live in the structure, not only in the visual gutters.
Announcement follows structure; visual reorder can split one list into two. Multi-column is the layout that most often never declares a path: the picture “looks like columns” while the tree may still walk by row.
Why it happens
Sighted readers use column geometry as scaffolding: a vertical seam appears, and they finish a column before changing columns. Assistive technology has no such geometry; it walks node order. If authors write source by visual row (left cell then right cell on every row), what is heard is “a sentence of article A, a sentence of article B.” If they write source by column (all of the left column, then the right), what is heard is two complete pieces.
Comparison columns (“Basic | Pro”) are stricter. The wanted path is often “finish one plan, then the other,” or “compare feature by feature across a row.” Both are legitimate; one must be chosen and executed in the structure. With no choice, the default is usually DOM row-major, fighting visual column-major, and listeners cannot rebuild “two plans versus one feature table” in their head.
Studying it
The same two-column content in three sources: column-major (left block then right), row-major (left-right interleaved), and shuffled. Screen-reader users listen, then retell how many articles or plans there were and the point of each. Dependent: whether independent texts can be separated, retell errors, reports of interleaving. Card grids take the same treatment: cards contiguous versus alternating across a row.
Viewing the source with CSS columns removed is a clean check: can you still see “these are two pieces”? If not, the path existed only in paint.
Where it stops holding
Real data tables have row and column semantics and a cell-by-cell move; they should not be flattened into one “left column then right column” path. A single column has no column-path to declare. Decorative multi-column (a row of unrelated badges) is weak if each item is independently intelligible. Print-magazine “heading spans columns, then back to the left column” is extremely hard to express in structure on a screen; it is usually better to drop columns and use sequential sections.
Applying it
- For every multi-column template, write one sentence: “finish a column then change, or compare left-right along a row.” Then make source order execute that sentence: independent articles or plans written as contiguous columns; feature comparisons written as row-wise pairs.
- Do not slice a continuous article with visual CSS columns unless you can accept the reader interleaving those columns — usually you cannot. Continuous prose stays a continuous structure; columns are for blocks that were already parallel.
- How to check: listen to the whole page with styles off. Independent columns should retell as independent stories; comparison columns should retell as “two values of the same feature.” If the retell becomes a sentence of A then a sentence of B, the source was written row-wise. Fix the tree; do not add a caption that says “please read left to right.”