The problem right now
Grid and Flexbox are already mainstream.
The problem is that of it being possible for DOM source order to not match the visual order. For example, this could mean that while using a keyboard you might tab into something which visually has been changed to someplace far away from the previous entry in the DOM, causing focus to jump around the page. For more info on this problem, see the following:
In almost all of the cases that I’ve seen of flexbox/grid changing visual order, that is the order in which it actually makes sense to consume the content. I.e, the visual order is the way in which most authors intend that the user consume the content.
Firefox used to have a ‘bug’ where keyboard focus follows the visual order, which actually was welcomed by many in the a11y community even though technically it was a bug. It’s since been ‘fixed’ to match other browsers .
It’s unlikely browsers will change their behaviour, especially to non-spec behaviour. The CSS WG had this discussion already and it’s unlikely that they will change the default behaviour . Besides, I’m pretty sure there are real-world use cases where you want DOM order to always match focus order, so changing existing behaviour to visual order by default seems a bad idea and would break existing sites which rely on this behaviour.
The following approach be interesting:
An attribute named
followorder with possible values
visual. No value for the attribute defaults to
default (DOM order).
If we have it on an element like
Then the child elements will receive focus (and have reading order on virtual cursor) according to the visual order (i.e, that Firefox ‘bug’ behaviour).
This could be good for the following reasons
- Default behaviour is untouched.
- Developers could explicitly choose which portion of the page receives focus in visual order. It’s an opt-in behaviour and won’t automatically affect existing implementation.
- If a different layout mechanism apart from flex and grid come up in the future, this would still work without changing it’s behaviour in that layout mechanism’s spec (hopefully). It’s better than making changes in the individual CSS specs regarding layout.
In other words, this solution doesn’t break the web and interop between browsers and would probably work better with future additions to layout specs.
It could solve a huge problem in accessibility which the web (as of now) does not have any clear answers to.
Feel free to shout at me that it’s a bad idea, in case it is. The details of how the visual ordering could/should work can be discussed and worked on - what I’m more interested is whether it seems like a good idea and whether there would be interest in browsers to consider implementing it.