Last month in my post Source Order Matters I wrote about why we need to consider how the source order of the HTML of a page can affect users when the CSS re-orders the content visually. While I used a recipe as an analogue and cited WCAG conformance rules, I failed to provide specific examples. I prepared one for my talk at Accessibility Camp Toronto, but have since expanded on it with more examples.
I want to make sure that we all understand that the source order versus display order discussion is not unique to CSS Flexbox. It is not unique to CSS Grids. Many developers have been dealing with this (correctly and incorrectly) since CSS floats and absolute positioning were introduced (and even earlier with tabled layouts). As such, I have examples of each in this post (no tabled layouts).
As you test these examples, make sure to use the Tab↹ key so you can understand how a screen reader or non-mouse user will experience the order versus how it appears. These all assume a left-to-right, top-to-bottom reading order.
There are other examples of how Flexbox ordering can change the expected (whether by user or developer) flow of focusable elements on a page. Alastair Campbell provides one showing a generalized page layout. Jules Ernst has one that also documents how browsers and screen readers behave. Right now Firefox is the outlier, as the following animated images demonstrate.
These animated images show how the tabbing sequence looks in Internet Explorer 11 and Firefox 41 (where Grid doesn’t work even with the flags enabled).
CSS Absolute Position
The questions about HTML source order versus CSS order are on the mind of both developers and standards bodies, which is a good sign that people are interested in making this work in a way that makes sense for everyone.
I have two suggestions which I will continue to follow until this is all sorted out…
If you are using CSS Flexbox, don’t use order, as that can be a can of worms.
Whether or not you have access to a screen reader, you can at least test your page with the keyboard by tabbing through. If the tab order doesn’t match the expectation based on the content, and if browsers all handle it differently, then you should reconsider your approach.
• Source order equals tab order makes the most sense developer wise.
• CSS order equals tab order makes sense visually.
I sort of lean toward CSS order as I think users benefit from that situation. Although this statement needs more research! This would also only work if AT followed the CSS order (which I don’t think they do).
Per Jules Ernst’s post, Firefox 41 follows Flexbox’s order declaration, but NVDA 2015.2 did not (even when paired with Firefox). I think Firefox is ultimately going to follow the other browsers and honor source order. I cannot speak to JAWS, VoiceOver, etc. I am happy to have people leave notes of what they find.
Regardless, your point about making sense visually is accurate. Expectations can be set by visual layout, creating an even bigger problem for a sighted keyboard user. That becomes even more apparent with Grid using the example I pulled right from the spec.
The issue still open against Firefox has a lot of discussion worth considering. It turns out this is not an easy issue to address and word is that at least one other browser is considering using the approach Firefox uses.