Re: flexbox review

Oops, this was supposed to have come from me. I don't know why my mail 
client said it was from Janina. Michael

On 20/05/2014 12:02 PM, Janina Sajka wrote:
> I've taken a stab at drafting this comment for sending to the CSS WG. 
> For a WG comment on a spec, we only need to comment on what they might 
> do in their specification, not on other ways we might tackle the issue 
> such as draft WCAG techniques. I also think it's mainly useful to 
> comment on what we want changed; saying what we like is nice to do 
> informally but doesn't really seem like a Last Call comment to me.
>
> Therefore, it seemed to me only the #3 in Cynthia's proposal is 
> something we would send to the CSS WG, and only the components of that 
> that relate do their spec. All the thoughts about WCAG techniques are 
> ones we should keep in mind (send to the WCAG WG, take an action to 
> develop, or something) but wouldn't be part of the WG comment to CSS. 
> With these principles in mind, my version of the candidate comment 
> follows. Does it seem ok and complete?
>
> Michael
>
> =====
>
> Below is a review from the Protocols and Formats Working Group on CSS 
> 3 Flexbox <http://www.w3.org/TR/2014/WD-css-flexbox-1-20140325/>.
>
> <blockquote>
> 5.4.1 Reordering and Accessibility
>
> The order property does not affect ordering in non-visual media (such 
> as speech). Likewise, order does not affect the default traversal 
> order of sequential navigation modes (such as cycling through links, 
> see e.g. nav-index [CSS3UI] or tabindex [HTML40]). Authors must use 
> order only for visual, not logical, reordering of content; style 
> sheets that use order to perform logical reordering are non-conforming.
>
> This is so that non-visual media and non-CSS UAs, which typically 
> present content linearly, can rely on a logical source order, while 
> order is used to tailor the visual order. (Since visual perception is 
> two-dimensional and non-linear, the desired visual order is not always 
> logical.)
> </blockquote>
>
> The reordering and accessibility section mentions tabindex and 
> nav-index. However, it's not quite strong enough on the importance of 
> focus order for visual keyboard users.
>
> We suggest to add "authors who change the order using order, 
> flex-direction=row-reverse, flex-direction=column-reverse, or 
> flex-flow (and ??) must|should adjust the focus order with either 
> nav-index or tabindex."
>
>
>
>
> On 07/05/2014 7:08 PM, Cynthia Shelly wrote:
>> Edited version:
>>
>> For the most part, I'm happy with flexbox.  It will be much easier to 
>> work with than absolute positioning and floats.
>>
>> 1.    Flexbox will likely have fewer order problems than absolute 
>> positioning for 2 reasons:
>> a.    It relies on the elements being near each other in the DOM, in 
>> a common container, so there will be less chance of elements getting 
>> adding to the DOM in an illogical order and positioned will-nilly.
>> b.    It is much easier to code, so there should be fewer errors in 
>> ordering.
>> 2.    They've added a section about order and accessibility, which 
>> addresses screen reader behavior, and brings it into alignment with 
>> WCAG 1.3.2 Meaningful Sequence.
>> 3.    The reordering and accessibility section mentions tabindex and 
>> nav-index, which are related to WCAG 2.4.3 Focus Order. However, I 
>> don't think it's quite strong enough on the importance of focus order 
>> for visual keyboard users.  I think this can be addressed with some 
>> minor edits.  I would add "authors who change the order using order, 
>> flex-direction=row-reverse, flex-direction=column-reverse, or 
>> flex-flow (and ??) must|should adjust the focus order with either 
>> nav-index or tabindex."
>>
>> Another option that wouldn't introduce a normative requirement would 
>> be to create a WCAG failure for this and link to it.
>>
>> I would like to see such a WCAG failure regardless of any changes in 
>> this spec, and a couple of techniques on how to use it accessibly.  I 
>> have some samples that avoid order and *-reverse.  We would also need 
>> one each using nav-index and tabindex.  We may find that tabindex is 
>> a bad idea, since it's markup and flexbox is css.
>>
>> WCAG Failure 1 [1] deals with 1.3.2, and we could add to that. I 
>> think we need to add another WCAG failure for 2.4.3 that deals with 
>> changing the tab order with CSS. This would be similar to Failure 44. 
>> [2]
>>
>> <blockqutote>
>> 5.4.1 Reordering and Accessibility
>> The order property does not affect ordering in non-visual media (such 
>> as speech). Likewise, order does not affect the default traversal 
>> order of sequential navigation modes (such as cycling through links, 
>> see e.g. nav-index [CSS3UI] or tabindex [HTML40]). Authors must use 
>> order only for visual, not logical, reordering of content; style 
>> sheets that use order to perform logical reordering are non-conforming.
>> This is so that non-visual media and non-CSS UAs, which typically 
>> present content linearly, can rely on a logical source order, while 
>> order is used to tailor the visual order. (Since visual perception is 
>> two-dimensional and non-linear, the desired visual order is not 
>> always logical.)
>> </blockquote>
>>
>> 4.    I didn't see anything else that concerned me.
>>
>> [1] http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140311/F1
>> [2] http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140311/F44
>>
>> -----Original Message-----
>> From: Janina Sajka [mailto:janina@rednote.net]
>> Sent: Tuesday, May 6, 2014 5:04 AM
>> To: public-pfwg@w3.org
>> Subject: Re: flexbox review
>>
>> Thanks, Cynthia, for this review.
>>
>> There having been no comments, I'm assuming PF does not disagree with 
>> the analysis? We'll take up the question of turning this evaluation 
>> into a PF response to CSS on this week's telecon.
>>
>> Janina
>>
>> Cynthia Shelly writes:
>>> For the most part, I'm happy with flexbox.  It will be much easier 
>>> to work with than absolute positioning and floats.
>>>
>>>
>>> 1.       Flexbox will likely have fewer order problems than absolute 
>>> positioning for 2 reasons:
>>>
>>> a.       It relies on the elements being near each other in the DOM, 
>>> in a common container, so there will be less chance of elements 
>>> getting adding to the DOM in an illogical order and positioned 
>>> will-nilly.
>>>
>>> b.      It is much easier to code, so there should be fewer errors 
>>> in ordering.
>>>
>>> 2.       They've added a section about order and accessibility, 
>>> which addresses screen reader behavior, and brings it into alignment 
>>> with WCAG 1.3.2 Meaningful Sequence.
>>>
>>> 3.       The reordering and accessibility section mentions tabindex 
>>> and nav-index, which are related to WCAG 2.4.3 Focus Order.  
>>> However, I don't think it's quite strong enough on the importance of 
>>> focus order for visual keyboard users.  I think this can be 
>>> addressed with some minor edits.  I would add "authors who change 
>>> the order using order, flex-direction=row-reverse, 
>>> flex-direction=column-reverse, or flex-flow (and ??) must|should 
>>> adjust the focus order with either nav-index or tabindex."
>>>
>>>
>>>
>>> Another option that wouldn't introduce a normative requirement would 
>>> be to create a WCAG failure for this and link to it. [aside: I 
>>> remember a WCAG failure for absolute positioning, but I don't see it 
>>> now.]  I would like to see such a WCAG failure regardless of any 
>>> changes in this spec, and a couple of techniques on how to use it 
>>> accessibly.  I have some samples that avoid order and *-reverse.  We 
>>> would also need one each using nav-index and tabindex.  We may find 
>>> that tabindex is a bad idea, since it's markup and flexbox is css.
>>>
>>>
>>> <blockqutote>
>>> 5.4.1 Reordering and Accessibility
>>>
>>> The order<http://www.w3.org/TR/css3-flexbox/#propdef-order> property 
>>> does not affect ordering in non-visual media (such as 
>>> speech<http://www.w3.org/TR/css3-speech/>). Likewise, 
>>> order<http://www.w3.org/TR/css3-flexbox/#propdef-order> does not 
>>> affect the default traversal order of sequential navigation modes 
>>> (such as cycling through links, see e.g. 
>>> nav-index<http://www.w3.org/TR/css3-ui/#nav-index0> 
>>> [CSS3UI]<http://www.w3.org/TR/css3-flexbox/#css3ui> or 
>>> tabindex<http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#adef-tabindex> 
>>> [HTML40]<http://www.w3.org/TR/css3-flexbox/#html40>). Authors must 
>>> use order<http://www.w3.org/TR/css3-flexbox/#propdef-order> only for 
>>> visual, not logical, reordering of content; style sheets that use 
>>> order<http://www.w3.org/TR/css3-flexbox/#propdef-order> to perform 
>>> logical reordering are non-conforming.
>>>
>>> This is so that non-visual media and non-CSS UAs, which typically
>>> present content linearly, can rely on a logical source order, while
>>> order<http://www.w3.org/TR/css3-flexbox/#propdef-order> is used to
>>> tailor the visual order. (Since visual perception is two-dimensional
>>> and non-linear, the desired visual order is not always logical.)
>>> </blockquote>
>>>
>>>
>>> 4.       I didn't see anything else that concerned me.
>>>
>

Received on Tuesday, 20 May 2014 16:03:57 UTC