Mobile layouts are not smaller desktop layouts: reading order before column count

On a desktop, a heading, its explanation, and an interface mockup can sit side by side. On a phone, they have to answer a more specific question: what does the reader need to see first to understand what follows?

Changing three columns to one does not answer that question. If an important limitation is far down the page, a link to act appears before the explanation it depends on, or a mockup fills the first screen, the content may all be there while readers still lose the thread.

I start by treating content as a path the reader can follow downward, then decide which parts are worth placing side by side on a wide screen. This note uses the structure of the site’s service, notes, and product pages recorded on October 24, 2026. It discusses ordering and implementation trade-offs; it does not claim that the mobile presentation has passed visual review.

Make the single-column sequence work before arranging desktop positions

Each service card on the site placed the service name and description first, followed by the items covered and additional limitations, and then the interface mockup. At medium widths, the text group and mockup formed two columns; at wider widths, the text group used display: contents so its contents could participate in the outer grid, forming three columns.

There was no separate copy of the card for mobile. Changing the column count still used the same headings, descriptions, and scope data. On a narrow screen, the sequence puts what the service handles before its scope and the mockup; it is not a proportionally scaled-down desktop view.

This also suggests a content check: set aside left and right placement for a moment and see whether the sequence of headings, paragraphs, and lists makes the section understandable on its own. If readers have to rely on “the image on the right” to understand a limitation, the relationship needs to be clearer in the text when the layout becomes a single column.

I start by organizing a single column, but that does not make one reading order mandatory for every site. News, comparison tables, and workflows may have different dependencies; the content itself determines what is needed.

Consider DOM order, visual placement, and focus order separately

CSS can place elements in different grid positions or rearrange them with order. Moving something earlier on screen does not mean that its position in the document or in keyboard navigation has changed with it.

W3C’s Meaningful Sequence requires a correct reading sequence to be programmatically determinable when the sequence affects meaning. It also explicitly allows for multiple valid sequences; it does not require every set of content to have only one possible arrangement.[1]

Swapping two independent article cards is therefore different from moving required instructions after a submit button. The former may still make sense, while the latter calls for checking whether people have the information they need before acting. Visual appeal alone cannot settle that question.

Keyboard navigation is another path that needs to be followed. W3C’s Focus Order is concerned with whether the focus sequence preserves meaning and operability, not whether every focusable element mechanically follows its visual coordinates.[2] If the visual flow goes from left to right but pressing Tab repeatedly jumps across sections the reader has not yet understood, that is a reason to revisit the layout and document structure.

I would not start by adding a series of positive tabindex values to compensate for content placed out of sequence on desktop. I first check content dependencies and the order of native links and controls, then address the layout that is actually needed.

The same cards need to accommodate different content lengths

The site’s regular note list used one column at narrower widths and two after its configured breakpoint. Both arrangements used the same article data and card component.

That only establishes a shared data source and rendering entry point. It does not show that every title length fits well. A short title and a two-line summary may align neatly, but a longer English or Japanese version may leave the link harder to find.

In a review, I would pick a card with both a long title and a substantial summary, then follow the category, title, summary, and reading link in order. I would check that the information is complete before looking at spacing, line breaks, and the rhythm between cards, rather than start with a fixed height that clips content because it is hard to lay out.

Featured cards had their own desktop grid placement, so the regular list’s natural flow cannot establish that nothing is reordered anywhere on the site. A responsive-layout check needs to name the kind of card and the container level it covers, rather than record only “mobile looks fine.”

Mockups do not always need to keep the same position

The feature-description area on the site’s product page placed the heading, description, and list before the interface mockup; on wide screens, the two groups sat side by side. The mockup area had aria-hidden="true"; the preceding text remained responsible for explaining the features.

The opening section of the product page used a different arrangement: at a particular narrow-screen breakpoint, the mockup area became absolutely positioned and sat behind the text with reduced opacity. Even within one page, stacking everything in order was not the only strategy.

The shared criterion is that readers should not have to decipher a tiny interface mockup before they can understand a sentence of explanation. Decoration can move into the background. If an image really contains important information that the text does not explain, hiding or fading it is not enough; it also needs an understandable alternative.

The mockups in service cards were also decorative structures, not product interfaces people could operate. Their position and proportions can change with the layout, but readers must not be led to believe that clicking the mockup is required to collaborate or read the content.

Read the whole sequence instead of checking only a few breakpoints

I would read from the beginning of a section to its call to action: first learn what it is, understand the relevant scope, read any necessary limitations, and finally see what I can do next. This makes breaks in the content easier to find than merely checking whether columns stack at a particular width.

The way I check also needs to change. After a visual pass, I would follow the keyboard path to the links and, where needed, inspect the accessibility tree and how assistive technology reads the content. Multilingual pages need their actual copy too; one set of short placeholders cannot stand in for every version.

Code, tables, and images in long articles have their own reflow problems; this note focuses on reading dependencies between sections. Both need real content, but one list check cannot also establish that the entire article layout has passed review.

This note describes the recorded structure and the review method I use. It does not provide a record of passing checks across all devices, full keyboard operation, or assistive technology, and it is not a WCAG conformance certification. The mobile layout still needs to be read by a person. If the content stops making sense when its side-by-side arrangement is removed, fix the sequence before fine-tuning column widths.

Sources

[1] https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html — W3C — Understanding SC 1.3.2 Meaningful Sequence [2] https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html — W3C — Understanding SC 2.4.3 Focus Order