FlexBox keyboard disconnect - new property proposal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

FlexBox keyboard disconnect - new property proposal

Léonie Watson-5
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/ 
--
@LeonieWatson tink.uk Carpe diem



Reply | Threaded
Open this post in threaded view
|

Re: FlexBox keyboard disconnect - new property proposal

Henrik Andersson
Léonie Watson skrev:

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

Reply | Threaded
Open this post in threaded view
|

RE: FlexBox keyboard disconnect - new property proposal

Léonie Watson-5
> From: Henrik Andersson [mailto:[hidden email]]
> 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.



Reply | Threaded
Open this post in threaded view
|

Re: FlexBox keyboard disconnect - new property proposal

Brian Kardell
In reply to this post by Léonie Watson-5


On Fri, Jun 17, 2016 at 5:53 AM, Léonie Watson <[hidden email]> wrote:

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

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






--
Brian Kardell :: @briankardell 
Reply | Threaded
Open this post in threaded view
|

Re: FlexBox keyboard disconnect - new property proposal

Tab Atkins Jr.
On Fri, Jun 17, 2016 at 7:52 AM, Brian Kardell <[hidden email]> wrote:
> On Fri, Jun 17, 2016 at 5:53 AM, Léonie Watson <[hidden email]> wrote:
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: FlexBox keyboard disconnect - new property proposal

Florian Rivoal-4

> On Jun 18, 2016, at 06:06, Tab Atkins Jr. <[hidden email]> wrote:
>
> On Fri, Jun 17, 2016 at 7:52 AM, Brian Kardell <[hidden email]> wrote:
>> On Fri, Jun 17, 2016 at 5:53 AM, Léonie Watson <[hidden email]> wrote:
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: FlexBox keyboard disconnect - new property proposal

Amelia Bellamy-Royds
Florian's point about there not necessarily being one clear "visual order" is something I've noted as well.  For flex-box containers there is a clear order, but for grid, floats, and absolute positioning it gets more complex.

Maybe there needs to be 2 different "visual" keywords: column-first versus row-first

i.e., for column-first you would work your way down the "start" (i.e., left for LTR text) edge of the page, including all boxes that touch that edge. Then you would find the boxes with the next-smallest left offset, and go through them top to bottom, and so on.

For row-first, you would do the reverse, sorting boxes first by their top offset, then by their left/right offset.

Another complication is how to handle nesting.  Do you group the sorting of boxes by stacking context, or by containment block? This is a property you'd often want to control sibling elements in a small region of the page (e.g., children of a flexbox container), but you may want the freedom to re-order elements who are nephews or cousins in the DOM tree.  

And for Brian: a few more examples of cases where a "keyboard disconnect" is useful:
  • Your navigation list includes a "HOME" link represented by company logo but also text links to various pages.  On wide screens, you want the HOME logo to be large in the middle of the header and the other links pushed to either side. On smaller screens, you want it all in a single column, with the logo at the top. For non-visual users, you don't want to re-order the items in the navigation list based on screen size, because that would be unnecessary confusion.  Even for sighted users, the visual prominence of the large center logo means it is naturally first, even if not first left-to-right.

  • You're presenting a Top 3 list of some sort using the Olympic medal podium as a visual representation. Left-to-right, the order is 2-1-3, but of course you want the entries to be still read out / tabbed through in 1-2-3 order.  Again, some sort of visual prominence or cross-axis alignment would be used to make the middle entry more prominent and obviously first to visual users.

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.

~Amelia

On 18 June 2016 at 17:01, Florian Rivoal <[hidden email]> wrote:

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).
Reply | Threaded
Open this post in threaded view
|

RE: FlexBox keyboard disconnect - new property proposal

Greg Whitworth
In reply to this post by Tab Atkins Jr.
>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 implementers due to its complexity.

~Greg

Reply | Threaded
Open this post in threaded view
|

Re: FlexBox keyboard disconnect - new property proposal

Florian Rivoal-4
In reply to this post by Amelia Bellamy-Royds

> On Jun 19, 2016, at 17:56, Amelia Bellamy-Royds <[hidden email]> wrote:
>
> 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