Re: [css-flexbox]

On Tue, Aug 25, 2015 at 7:51 PM, Bo J Campbell <bcampbell@us.ibm.com> wrote:
> I am returning to Flexbox Order in regard to accessibility, usability and
> the limitation of functionality by forcing a change of DOM to change the
> focus order.
>
> The suggestion is to create an attribute that states whether the tab order
> of Flexboxes should follow the visual order or the original logical order
> after they are reordered.
>
> In regard to accessibility, WCAG is currently overly specific and outdated
> in regard to a meaningful sequence of content. Developers need the ability
> to reorder content and not risk creating accessibility issues by having the
> focus jump all over the screen. Flexbox is incredibly powerful but extremely
> risky when it comes to accessibility. An attribute that could keep a tab
> order the same as the visual order will allow developers to use Flexbox and
> make individual accessibility judgments on the interactions.
>
> But this is not just an accessibility solution. For instance, consider a row
> of buttons that can be rearranged by the user. When Flexbox is used to
> display the new button order, the tab will jump in a non-linear fashion.
> WCAG does not specifically judge this as a violation, yet tabbing across
> buttons with the focus jumping back and forth is a very bad experience for
> any user, especially those with cognitive disabilities and/or using a
> keboard.
>
> One may suggest coding alternatives to any example, but a Flexbox attribute
> solves the issues for usability as well as accessibility no matter how
> creative a developer gets with it.
>
> Best,
> Bo Campbell
>
>

I've been thinking about this quite a lot myself - not your specific
proposal but the challenge of reordering elements visually in
potentially radical-ish ways and what that means to accessibility.  I
think we've been punting on this kind of thing for a while because it
mostly affects "new" specs in very obvious ways but in reality I think
there might even be more to it with already existing specs that we're
just finally getting enough experience with to notice.

For example, with positioning/media queries you can get the weird
experience you were describing as well.  A lot of sites have some user
data above the main menu (I'm not arguing this is right or wrong, it
just is what it is) and then as you resize the screen (or have a lower
resolution crossing a breakpoint) this can change and you get a
hamburger menu which appears visually before the user data.  In this
case, when you tab into the document your first focus is not the first
visual element, then after 1...N tabs your focus shifts back to what
is the visual first element, then away to whatever is N+1.

That's pretty bad on it's own, as you describe, but there's maybe
something even subtler lurking here too.  Maybe this seemingly silly
question will make it a little more evident what I am saying:  What's
the resolution on a blind user's computer?
The reason I ask is that, for example, if you are using a touch device
for non-sequential navigation - it entirely matters.  You're might be
fishing fingers around a touch screen to understand it and obviously
you can't touch what isn't there.  However, if you are using a
keyboard for sequential navigation and you can't actually see the
screen, it doesn't - and it means that we might be affecting users for
no good reason.   This means then that your OS resolution might
actually matter in non-trivial ways if you're not thinking about it.
In the case I laid out above, the document itself has an original/true
order and if you're blind and using a reader, in this case the order
is maintained and 'correct' and "fixing" the visual order *might*
actually make that problem potentially worse - it's suddenly variable
based on the machine for no seemingly good reason.

Overall, I think sequential navigation needs some more
thought/ideas/help/evolution.

-- 
Brian Kardell :: @briankardell :: hitchjs.com

Received on Wednesday, 26 August 2015 16:50:05 UTC