Re: [css-flexbox] Accessibility of Order

Brad Kemper


>> On Jan 9, 2015, at 5:01 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 
>> On Fri, Jan 9, 2015 at 4:12 PM, Bo J Campbell <bcampbell@us.ibm.com> wrote:
>> I have added a general example of the reason why the tab order needs to be
>> updated to match the visual order when it is changed via Flexbox Order. In
>> turn, the accessibility API should also get the same visual flow.
>> 
>> https://wiki.csswg.org/spec/css3-flexbox/accessibility
>> 
>> I would like to continue understanding any further arguments stopping this
>> proposal since PF is asking for this, IBM and Freedom Scientific agree this
>> is what needs to happen, and I believe I have addressed the arguments made
>> so far in the wiki document.
> 
> Your examples are all trivial, and don't illustrate one of the primary
> use-cases for 'order', such as Example 7 in the spec, where the
> *intended behavior* is to put the main content first in the markup
> *precisely so that* it will show up first in tabbing order, and then
> visually arrange the sidebars relative to the main content in some
> arbitrary style-dependent way.
> 
> We continue to bring this up as a counter-example every time, and it's
> somewhat frustrating to see it continually brushed aside in favor of
> trivial examples that don't provide compelling reasons to preserve
> source order.

I agree with Tab. The order property finally allows the source content to be in the best logical order, while CSS only makes stylistic changes. A navigation bar is secondary to the main content and so should come after the main content in the source, even if it is typical to visually arrange it on the top or left side. Blind or not, nobody should have to tab past the navigation to get to the main content on each page. 

I think if there is a lot of interest to have reading software for the blind read the nav bars first because of their visual arrangement (as unlikely as that seems), then such software should have a mode in which it ignores tabindex, nav-index, and DOM order, and only look at where the top left corner of each element is in some rendered view. But that would not be the normal, most useful mode for properly designed source. 

The biggest and oldest idea of CSS is that is separates style from content, and that it is not intended as a fix for poorly structured content (although it does sometimes help with that, it is always better if the content is structured well). 

The arguments to change this major accessibility feature do seem weak. 

JavaScript is the better tool to change DOM order if it DOM order has been poorly design in the source. The speed of CSS is not a good reason for it to its accessibility features to be reversed in order to fix accessibility problems authored in a different language (html), instead fixing them in the source or by using a language (such as JavaScript) designed to be able to alter the DOM. That was never what CSS was for, and it certainly isn't why the 'order' property was added to flexbox. 

Nav-index (and other things in the UI spec) is about as far as CSS goes into being more about function than style, and it should be able to help if you really want to use CSS to change the tabbing order to get to navigation bars before you get to content. 

A blind user calling a help line is not going to get much from a visual description anyway, but a help line representative _would_ have a tab key on the keyboard in which to traverse the document in the same order as the screen reading software. 

The PF Group was not against the language in the spec, they just wanted language added that would encourage authors to use tabindex and nav-index to ensure a good traversal order (assuming the source order was not already in the best order and would be harder to change).

Received on Saturday, 10 January 2015 06:44:04 UTC