FlexBox keyboard disconnect - new property proposal

[Léonie Watson]

Hello CSS,

Had an impromptu chat with Simon Pieters and Greg Whitworth about the
FlexBox keyboard disconect [1]. It resulted in an idea for a new CSS
property...

At the moment the problem is that FlexBox can create a disconnect between
the DOM order and visual order. This affects sighted keyboard users - or at
least exacerbates the disconnect that has existed since CSS layouts were
first a thing.

There is a workaround in Firefox, whereby the keyboard order matches the
visual flex order, instead of the DOM order. On the face of it this seems
like a good solution, but Simon made a good point - what happens when the
keyboard disconnect is actually useful?

It seems like it would be good to have a property to enable developers to
choose whether the keyboard order matched the DOM order or the flex order.
Off the top of my head, something like:

tab-order: dom;

or:

tab-order: flex;

From the work Mozilla has already done, and this briefest of conversations

with Greg and Simon, it seems there is energy from the browser vendors to
find a solution to this problem. Hoping this idea kicks off further
discussion...

Léonie.
[1] http://tink.uk/flexbox-the-keyboard-navigation-disconnect/

[Henrik Andersson]

Post by Léonie Watson
Hello CSS,
Had an impromptu chat with Simon Pieters and Greg Whitworth about the
FlexBox keyboard disconect [1]. It resulted in an idea for a new CSS
property...
At the moment the problem is that FlexBox can create a disconnect between
the DOM order and visual order. This affects sighted keyboard users - or at
least exacerbates the disconnect that has existed since CSS layouts were
first a thing.
There is a workaround in Firefox, whereby the keyboard order matches the
visual flex order, instead of the DOM order. On the face of it this seems
like a good solution, but Simon made a good point - what happens when the
keyboard disconnect is actually useful?
It seems like it would be good to have a property to enable developers to
choose whether the keyboard order matched the DOM order or the flex order.
tab-order: dom;
tab-order: flex;

From the work Mozilla has already done, and this briefest of conversations

with Greg and Simon, it seems there is energy from the browser vendors to
find a solution to this problem. Hoping this idea kicks off further
discussion...
Léonie.
[1] http://tink.uk/flexbox-the-keyboard-navigation-disconnect/

Nice idea in theory, but you seem to be focusing too much on flex being
the only tab ordering affecting layout module. I'd try to avoid layout
module specific keywords here.

[Léonie Watson]

Sent: 17 June 2016 13:31
Nice idea in theory, but you seem to be focusing too much on flex being

the

only tab ordering affecting layout module. I'd try to avoid layout module
specific keywords here.

Thanks for the feedback Henrik. Can you suggest some less specific language
to help guide this idea in the right direction?

Léonie.

[Brian Kardell]

On Fri, Jun 17, 2016 at 5:53 AM, Léonie Watson <***@tink.uk> wrote:

[snip]

Post by Léonie Watson
On the face of it this seems
like a good solution, but Simon made a good point - what happens when the
keyboard disconnect is actually useful?

Can you provide an example where the keyboard disconnect is actually
useful? I'm not saying such a case doesn't exist, simply that it is
non-obvious and if that is a use-case it would be helpful to have an
example documented.

Post by Léonie Watson
Léonie.
[1] http://tink.uk/flexbox-the-keyboard-navigation-disconnect/
--
@LeonieWatson tink.uk Carpe diem

[Tab Atkins Jr.]

Post by Léonie Watson
On the face of it this seems
like a good solution, but Simon made a good point - what happens when the
keyboard disconnect is actually useful?

Can you provide an example where the keyboard disconnect is actually useful?
I'm not saying such a case doesn't exist, simply that it is non-obvious and
if that is a use-case it would be helpful to have an example documented.

Long-standing accessibility advice is to put your "main content" first
in the DOM and things like sidebars and advertising later, using CSS
to arrange them as desired. This is the origin of the "holy grail
layout" (float-based) and similar CSS hackery - Flexbox handles these
cases much easier (example in
<https://drafts.csswg.org/css-flexbox/#order-accessibility>). Or
check out the Grid example
<https://drafts.csswg.org/css-grid/#source-independence> - the
portrait and landscape layouts are slightly different in visual order,
but each layout makes a lot of sense individually.

As Henrik said (and fantasai and I and others have repeatedly said in
the past), this has nothing to do with flexbox itself - CSS offers a
wealth of ways to lay out a page such that the visual and DOM orders
don't match. And there's more than just tab order that are affected
by the mismatch - for example, selecting text across element
boundaries gets frankly *silly* when you move elements around in
interesting ways, where highlighting from one point to another can end
up highlighting completely unexpected parts of the page.

So there are some complicated intersections of issues. Tab order is
relatively simple conceptually - one can imagine a simple switch (in
CSS or elsewhere) that resets the way tab-ordering is figured within
the subtree to match the (writing-mode determined?) visual order.
There's more detail to be worked out there, but it's not too hard to
imagine.

Selection is a much thornier issue, because (a) I think you might
*always* want visual selection? Can't think of when you'd *want* DOM
selection, and (b) you actually have to change the relevant API, to
return a multi-range object.

Anyway, I'm supportive of an effort to help things here, but we'll
need implementor interest in changing their tab-order implementation
to be significantly more complex.

~TJ

[Florian Rivoal]

Post by Tab Atkins Jr.

Post by Léonie Watson
On the face of it this seems
like a good solution, but Simon made a good point - what happens when the
keyboard disconnect is actually useful?

Can you provide an example where the keyboard disconnect is actually useful?
I'm not saying such a case doesn't exist, simply that it is non-obvious and
if that is a use-case it would be helpful to have an example documented.

Long-standing accessibility advice is to put your "main content" first
in the DOM and things like sidebars and advertising later, using CSS
to arrange them as desired. This is the origin of the "holy grail
layout" (float-based) and similar CSS hackery - Flexbox handles these
cases much easier (example in
<https://drafts.csswg.org/css-flexbox/#order-accessibility>). Or
check out the Grid example
<https://drafts.csswg.org/css-grid/#source-independence> - the
portrait and landscape layouts are slightly different in visual order,
but each layout makes a lot of sense individually.
As Henrik said (and fantasai and I and others have repeatedly said in
the past), this has nothing to do with flexbox itself - CSS offers a
wealth of ways to lay out a page such that the visual and DOM orders
don't match.

I would also add that not only can the visual order and the DOM order
get out of sync, since the visual rendering is a 2D thing rather than
a linear one, There isn't necessarily an order. Some 2D documents are
still essentially linear (e.g. top menu, then content, then footer),
but many are not (e.g. same thing with side bars, or anything a tad
complex).

- Florian

[Amelia Bellamy-Royds]

This post might be inappropriate. Click to display it.

[Florian Rivoal]

Maybe there needs to be 2 different "visual" keywords: column-first versus row-first
[...]
Another complication is how to handle nesting.

I think as soon as you try to do visual 2D navigation rather than logical order navigation, there's a whole host of complications. Nesting, grid layouts, complex layouts that not only aren't linear but don't even fit in rows and columns, implied hierarchy via size or color or contrast, overlapping elements and transparency, animated things that move around or disappear...

Heuristics to get this right are hard and will fail occasionally, and that's why we have https://drafts.csswg.org/css-ui/#keyboard

The issue of 2D keyboard navigation is something we've discussed often in the SVG Accessibility Task Force. One thing that would be helpful is for user agents to offer alternative ways for keyboard users to move around the page, other than tab order. Specifically, if you could press a modifier key and then use arrows to jump from one region to another based on actual layout. That's probably a separate and additional feature to what is proposed here, but I wanted to mention it.

Right. I think that's what it boils down to: either you want a linear logical order with a meaningful next and previous, and it is DOM based, or you want full spatial navigation with up/down/left/right, and it is layout based.

Both are useful, both should be possible to use in the same browsing context, but they are different, and trying to address layout-based concerns in the logical order sounds like an intractable problem to me.

If anyone want to try spatial navigation out and haven't yet, I've blogged about how it works in a few browsers: http://florian.rivoal.net/blog/2015/04/controlling-spatial-navigation/

- Florian

[Greg Whitworth]

As Henrik said (and fantasai and I and others have repeatedly said in the past), this has nothing to do with flexbox itself -
CSS offers a wealth of ways to lay out a page such that the visual and DOM orders don't match.

<snip>

Anyway, I'm supportive of an effort to help things here, but we'll need
implementor interest in changing their tab-order implementation to be
significantly more complex.
~TJ

+Alan/Rossen for visibility

A little clarification,

This is similar to what Simon and I stated in this brief discussion, that this is not flex specific, so we shouldn't focus purely on the layout mode for the underlying issue. Additionally, we stated that we need to have the full CSSWG present for the discussion as the property suggestion was merely one potential way to solve the problem and would require feedback from