Flexbox is a CSS technique for positioning content in rows and columns in a way that adapts well to responsive layouts. Flex items can grow or shrink to fit neatly within the space that they occupy, but their structure is not constrained to the rigid row-and-column model used in tables. Flexbox elements can also reposition themselves from row to row as needed.
This is all well and good visually, but what about the screen reader experience?
The Problem
The hitch is, while the eye can explore the content in two dimensions, a screen reader necessarily linearizes the content into a one-dimensional stream. The visually-implicit reading order of a flexbox presentation may or may not match this linear order, which is based on the DOM order. This mismatch can create reading order problems that could confuse users and possibly fail WCAG 1.3.2 (Meaningful Sequence).
Here’s an example that uses flexbox to support a basic responsive whole-page layout with a header, main, footer, and two aside regions.
This is the main content. This is the region of the page that contains the most relevant information on this topic.
Here you can learn more about our essential and delightful array of efficient and stylish products and our convenient financing options.
also enjoy…
Navigation
The CSS order property has been used deliberately to visually position the main and aside containers in an order that differs from the DOM order (which remains the screen reader reading order). This property uses an integer (e.g., order:2) to impose an artificial visual display order–but it does not impact the screen reader reading order. Although it’s probably an overstatement to advise against ever using the order property, it should be used with caution and tested with a screen reader.
Here’s another example, which presents a set of instructions in two visual columns. Since this example presents a step-by-step sequence, reading order is key.
How to Make Shortbread in 6 Easy Steps
Preheat the oven to 300 F.
Pat the dough in the bottom of an ungreased 9×13 baking pan.
Cream butter and sugar.
Bake at 300 F for 30 to 40 minutes, until just lightly browned.
Gradually stir flour into the creamed mixture until blended.
Remove from oven and pierce all over with a fork.
So long as the container is narrow, the instructions are presented visually as two columns. However, if we widen the view, six boxes are presented in a row–and the true reading order (DOM order) becomes apparent. (The order attribute has not been used in this example.) The DOM order does not match the intended order for the user to follow the steps.
How to Make Shortbread in 6 Easy Steps
Preheat the oven to 300 F.
Pat the dough in the bottom of an ungreased 9×13 baking pan.
Cream butter and sugar.
Bake at 300 F for 30 to 40 minutes, until just lightly browned.
Gradually stir flour into the creamed mixture until blended.
Remove from oven and pierce all over with a fork.
The Solution
For both examples, the key is to begin with a DOM order that reflects the correct or intended reading order, and then to ensure that visual presentations (at all widths) convey that order.
Ultimately, the takeaway is not that flexbox is dangerous, but that it is powerful. Use it, but use it wisely. Also, screen reader testing–of full-size and responsive layouts–will quickly reveal inequivalences that may otherwise go unnoticed visually.
To learn more about flexbox, we recommend Mozilla’s flexbox tutorial.
Consider a card component used on many websites. Within the card, there is the title of the post and a thumbnail of an associated image. The DOM order (source code) has the Title coming before the thumbnail.
Visually, the order is reversed with the thumbnail coming before the title of the post. Why would this be a problem for a screen reader user? The most important part of the card is the Title, which will be encountered first.
Yes, if you read Understanding Success Criterion 1.3.2: Meaningful Sequence, the takeaway is how the order of content affects the overall meaning. The criterion even mentions that there may exist more than one correct order.
In my example, the meaning, or purpose, of the card is not affected at all by reversing the order of the title and thumbnail.
In your example using a step-by-step sequence, this is not a consequence of using Flexbox. No, this is a developer problem. To achieve your example, one would have to code those steps out of logical order, deliberately, which wouldn’t make sense.
This post seems to be a poorly veiled attack on using Flexbox, using bad examples, and not reading all parts of the respective success criterion.
As long as the intended and reasonably expected meaning is not affected, re-ordering content sections on a well-structured webpage poses zero danger to the screen reader user and non-user.
H.E.A.T. raises a concern about being too strict on re-ordering content. To H.E.A.T.’s point, a “card” control is often a valid exception. Many accessibility-first card patterns will cite the re-ordering approach (I recommend it in my own pattern example).
The scope of this post is a page of content, so broadly authors should not re-order without a good reason (the card pattern is often a good reason, but not a page-level container). This is why the recipe example (oft-repeated, in fact) in this post is such a good example, even if it doesn’t necessarily scale up to an entire page by word count alone.
Bear in mind that the concerns outlined in this post are not restricted to flexbox; CSS grid has the same concerns. Pre-dating flex and grid, floats and absolute positioning both risk the same content order issues. If we go back even further, table layouts were such a challenge for text-only browsers (Lynx), that developers were counseled to build their tables to linearize well.
In short, content order and layout order mismatch has been a risk since layout features were introduced to the web, and will continue to be a risk as new layout features are created.