# How do we reorder a responsive layout without making keyboard and screen-reader navigation confusing? > Keep the DOM order as the meaningful task sequence across breakpoints, and use CSS reordering only for visual placement that does not change meaning. Canonical URL: https://www.devobs.io/articles/qa-responsive-visual-order-dom-order/ By: Nina Patel Published: 2025-07-05T20:40:18.572Z Updated: 2026-09-06T10:18:15.722Z Section: Architecture Use DOM order as the stable sequence for reading, focus, and task completion, and let responsive CSS change placement only when that does not change meaning. If a different breakpoint would need a different logical sequence, change the markup or component structure instead of trying to patch behavior with visual reordering. [WCAG 2.2 Meaningful Sequence](https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html) is the right starting point because users and user agents need at least one correct programmatically determinable reading sequence, and non-visual presentation and default sequential navigation commonly follow source order as the [CSS Flexible Box Layout Module Level 1 spec](https://www.w3.org/TR/css-flexbox-1/#order-accessibility) explains. ## What should be the source of truth for order? The source of truth should be the order that still makes sense when the page is linearized, zoomed, or restyled. [WCAG 2.2 Meaningful Sequence](https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html) says to use code to preserve meaningful content order and requires that, when sequence affects meaning, “a correct reading sequence can be programmatically determined.” It also makes an important boundary clear: only sequences that affect meaning must be fixed, and only one correct order needs to be provided. That means desktop composition is not your primary design constraint. If users must read instructions before acting, or set filters before interpreting results, that sequence belongs in the DOM. Visual layout can then place regions into columns, sidebars, or cards. WCAG also notes that navigation and side content can appear in different visual positions when understanding does not depend on their relative order. ## When is visual reordering safe? Visual reordering is safe only when it does not create a conflicting task sequence. Moving complementary content around a page can be fine. Moving step labels, validation guidance, submit actions, or dependent controls ahead of the content they explain is not. Be careful with flex and grid features that tempt you to solve a content problem as a layout problem. The [CSS Flexible Box Layout Module Level 1 spec](https://www.w3.org/TR/css-flexbox-1/#order-accessibility) explicitly says flex items keep their logical order from the source document for non-visual media and default sequential navigation, even when the `order` property changes visual placement. It goes further and says authors must use `order` only for visual, not logical, reordering of content. In practice, that leads to a simple rule: if keyboard or screen-reader order conflicts with the task sequence users need to understand or complete the page, your DOM order is probably wrong for that layout. ## How does this work in a responsive filters-and-results layout? A good worked example is a search page with filters, results, and a saved-items panel. Use this DOM order: 1. Page title and result summary 2. Filter trigger or visible filters 3. Results list 4. Saved-items panel On desktop, place filters in a left sidebar and saved items on the right with grid or flexbox. On mobile, let the same order stack naturally. That approach matches WCAG’s requirement to preserve a meaningful sequence in code while still allowing visual rearrangement that does not change meaning, and it matches the Flexbox spec’s guidance that source order remains the logical order for sequential navigation and non-visual presentation ([WCAG 2.2 Meaningful Sequence](https://www.w3.org/WAI/WCAG22/Understanding/meaningful-sequence.html), [CSS Flexible Box Layout Module Level 1](https://www.w3.org/TR/css-flexbox-1/#order-accessibility)). Decision checklist: - If CSS failed to load, would the page still read sensibly? - At high zoom or narrow reflow, does the task sequence still hold? - Does Tab move through controls in the same order users encounter instructions? - Are hidden or collapsed controls removed from focus order? - If you duplicate a control for different breakpoints, is only one exposed to users and assistive tech at a time? ## Should `tabindex` fix the order? No. The Flexbox spec notes that source order is used for the default traversal order of sequential navigation modes such as cycling through links, and changing visual placement with CSS does not repair an incoherent logical sequence ([CSS Flexible Box Layout Module Level 1](https://www.w3.org/TR/css-flexbox-1/#order-accessibility)). `tabindex` can alter focus order, but it does not repair reading order or make the structure easier to maintain. Use it for local widget behavior when needed, not to compensate for a broken page sequence. ## What changes when content collapses? Collapse changes visibility, not logical order. Keep the collapsed content in a place that still makes sense in the DOM, move focus into newly opened panels when appropriate, and return focus to the trigger when closing them. The order should remain coherent whether the panel is expanded, collapsed, or restyled. Your next step is to print the page regions in DOM order, then test one breakpoint with only Tab and one with a screen reader before you touch CSS placement. Reviewed: 2026-09-06 ## Source references - -