[Proposal] new attribute for specifying focus and reading order

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:

• Leonie Watson wrote about it here https://tink.uk/flexbox-the-keyboard-navigation-disconnect/
• Also Susan Robertson https://bocoup.com/blog/css-grid-responsive-and-accessibility
• And Alastair Campbell https://alastairc.ac/2017/06/the-responsive-order-conflict/

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 [1].

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 [2]. 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.

Proposed solution

The following approach be interesting:

An attribute named followorder with possible values default and visual. No value for the attribute defaults to default (DOM order).

If we have it on an element like

<div followorder="visual">
..
</div>

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).

Benefits

This could be good for the following reasons

1. Default behaviour is untouched.
2. 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.
3. 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.

• [1] bugzilla.mozilla.org/show_bug.cgi?id=812687
• [2] https://bugzilla.mozilla.org/show_bug.cgi?id=812687#c29

But this is in the document and the problem is that the stylesheet is changing the presentation order of the document visually but not audibly etc.

Multiple stylesheets for the same document might need different values for the attribute.

So i think it it should be a CSS property.

It’s not just about reading order, but also the order in which elements will recieve focus. So this isn’t just about screen readers, but also about people using keyboard for navigating a page.

agree that this should be in CSS. a way to signal “yes, i’m changing the order of this, and i want the browser to take this into account when working out the correct reading and focus order”.

Sure. I’m not particularly married to the thought of an html attribute as such - The only things with the CSS that I can see of is that it should need to be scoped independent of one layout spec or another (i.e, not limited to just the grid spec or flexbox etc). It would need to be independent of it, so that no matter what layout solution you’re using, it can apply.

This is good feedback. Any other thoughts everyone?

I’m totally for having this in CSS (something like follow-order property?), but even having some control in HTML would be better than not having it at all.

One thing I’d want to mention: I think the “visual” keyword can be really hard to implement, as there are too many things to consider, especially when there are animations and transitions.

What I’d propose is to call it “flow” or something like that — as in most of the cases where we’d have the difference between visual order and DOM order would come from changing the flow: order property, float, flex-direction, swapping stuff in grids via grid-row, grid-column and grid-area (as well as with an auto-placement algorithm, which could be probably the hardest thing for this feature?).

Optional way to follow the flow should be much easier to implement than to follow the strict visual order, and would be much easier to control as well.

Thanks for linking to my article. There are a couple of principles I’d like apply to any solution:

1. There is one interface. I.e. it shouldn’t be different for keyboard users and screenreader users. Ideally, the accessibility should follow the visual design/priority so there is only one version of any paricular interface.

2. The default code developers use should be accessible. I.e. if the browsers / AT can do something to make standard web-dev code accessible, do that instead of trying to getting web devs to add something just for accessibility ('cause it won’t happen, enough).

So in this case the soution should:

• Use the flexbox order as the keyboard / screenreader order.
• Use a row-by-row, column-by-column approach to the order through grid.
• Have a CSS property to override that default order.

I’d assume that means the browsers would need to change how ordering works for keyboard focus and in the accessibility tree, but not necessarily the DOM order?

So in this case the solution should:

• Use the flexbox order as the keyboard / screenreader order.
• Use a row-by-row, column-by-column approach to the order through grid.
• Have a CSS property to override that default order.

+1 to the browser matching the keyboard/screen reader order to the presentation order, and any attribute/property being “opt out” rather than “opt in”.

Either way the browser is going to need to update both the keyboard tab order and the accessibility tree, or to do something similar to the way Firefox approached it with the Flexbox “bug” and implement the solution somewhere between the DOM and the acc tree.

I would like that too! As you say it’s always better to have a opt-out solution than opt-in.

However, unless I’m not fully understanding what you wrote above, browsers (and the CSS WG) have indicated that browsers will follow DOM order and not the flexbox order when it comes to the keyboard/screen reader order… and it doesn’t seem like they are interested in changing it.

If we can get all browsers to change their default behaviour then great! That would be ideal, but realistically speaking, I don’t think there is much chance of it happening. Hence, this opt-in solution so that we have at least something to fix it.

It depends why they didn’t want to change it. If it is due to overhead then none of the options we are discussing would overcome that. Whatever the default way is, if there is another order the level of work required will be about the same.

If it is about changing a default way of doing the focus order, perhaps we can persuade them to change it. The evidence will pile up fairly quickly now that grids is well supported and people are starting to use it, but the later it is left, the more sites will be changed because of it.