Re: 2.4.3, 1.3.2

On Sun, Aug 14, 2011 at 11:34 PM, adam solomon <adam.solomon2@gmail.com>wrote:

> Take the bride/groom example. The author wants to streamline the form
> submission process by making it easier to fill out, one person at a time
> instead of row by row. Great. Here we have to decide what would be the case
> if he doesn't streamline by changing the tab order - are we in violation of
> 1.3.2 or not? Is traversing the form row-wise inherently illogical or not? I
> don't know, but let's look at both sides of the coin. If we decide that the
> default reading order is not logical, and we violate 1.3.2, then throw H4 in
> the bin, because correcting tab order will not correct reading order, and
> anyway we have a violation of 1.3.2.
> But, it seems that we really have decided that there is no violation of
> 1.3.2, since there can be more than one logical reading order. If so, even
> if the author does not add that extra tab order tweak to make things
> slightly more user friendly, there exists no violation of 2.4.3, since
> traversing row-wise, reading order or tab order, is fine with WCAG. Oh sure,
> it would be more user friendly to traverse person-wise, but that has nothing
> to do with WCAG conformance. Which brings me back to the original point -
> this technique does not actively satisfy anything, it is only saying to the
> author don't change the tab order in a bad way, just make sure it stays
> logical, which is in effect saying don't fail. But we already have a failure
> listed for 2.4.3 about not misusing tabindex.
>

Right. In the H4 examples, if the author just used the default tab order, he
would pass  G59, so that is how he would meet 2.4.3. There are other SC
where it is not possible to meet all the different sufficient techniques
simultaneously; some of them conflict with one another.

The failure is included because there are many ways of using tabindex that
do not result in a logical order. I think the general wisdom is that using
tabindex correctly is difficult, and tends to cause maintenance problems, so
we think authors are better off not using it. But using tabindex is not
always a failure.


> On Mon, Aug 15, 2011 at 9:19 AM, Gregg Vanderheiden <gv@trace.wisc.edu>wrote:
>
>> Adam
>> I think I see your question.
>>
>> You are saying  "if H4 is a sufficient technique - what is it sufficient
>> for?"   Most 'sufficient' techniques are 'sufficient to meet this SC'.    In
>> this case  "nothing" would be sufficient if the natural reading order would
>> be a logical reading order.    But changing it like this would 'also be
>> sufficient to meet the SC.
>>
>> As to 1.3.2 -- how do you think it would violate 1.3.2?
>>
>> 1.3.2 only require A logical reading order.  There isn't necessarily "a
>> single logical reading order".
>>
>> For tables - there are usually two (or more) logical reading orders.  In
>> fact sometimes I have presented tables in two fashions for accessibility
>> (though that is definitely not required)
>>
>>
>>    *Gregg*
>> --------------------------------------------------------
>> Gregg Vanderheiden Ph.D.
>> Director Trace R&D Center
>> Professor Industrial & Systems Engineering
>> and Biomedical Engineering
>> University of Wisconsin-Madison
>>
>> Co-Director, Raising the Floor - International
>> and the Global Public Inclusive Infrastructure Project
>> http://Raisingthefloor.org   ---   http://GPII.net
>>
>>
>>
>>
>>
>>
>>
>>
>> On Aug 15, 2011, at 1:11 AM, Loretta Guarino Reid wrote:
>>
>> I think you are saying that because the default tab order would conform to
>> WCAG, there is no need for a technique that changes the tab order.
>>
>> But changing the tab order is permissible under WCAG as long as the
>> resulting order "makes sense". And if the author thinks that changing the
>> tab order improves the usability, we want to make it clear that this still
>> conforms. So although the author did not need to change the tab order in any
>> of the H4 examples, changing it in these ways does not violate WCAG.
>>
>> Is there something different about tabindex in HTML5? If not, we may not
>> need an additional technique. We may just need to see whether H4 applies to
>> HTML5, as well, or can be modified so that it is clear that it also applies
>> to HTML5.
>>
>> On Sun, Aug 14, 2011 at 11:03 PM, adam solomon <adam.solomon2@gmail.com>wrote:
>>
>>> I guess I am just missing something. I still feel that sufficient
>>> techniques, though not being the only option for satisfying a success
>>> criterion, do in fact come to correct some deficiency in the web page. Sure,
>>> there are other ways to do it, but the deficiency needs to be addressed one
>>> way or the other. In H4, there is no deficiency by WCAG standards. Since the
>>> reading order is acceptable (if it weren't, we couldn't use this technique
>>> anyway since it violates 1.3.2), the focus order must also be acceptable by
>>> definition, and the added benefit of reading one person at a time in the
>>> bride/groom example adds no WCAG success to the web page, and addresses no
>>> WCAG deficiency.
>>> If you all still think that this is a valid technique, then I will draft
>>> the html5 technique in accordance with this one, and hopefully have it ready
>>> for this week's meeting.
>>>
>>>
>>>
>>> On Mon, Aug 15, 2011 at 8:51 AM, Loretta Guarino Reid <
>>> lorettaguarino@google.com> wrote:
>>>
>>>> Adam, I am still having trouble understanding why you think the
>>>> inclusion of the HTML tabindex technique is a problem.
>>>>
>>>> I think you are claiming that it is unnecessary? That it is always
>>>> possible to use a different technique to satisfy the success criterion? Am I
>>>> understanding that correctly?
>>>>
>>>> Loretta
>>>>
>>>>
>>>>
>>>> On Sun, Aug 14, 2011 at 10:46 PM, adam solomon <adam.solomon2@gmail.com
>>>> > wrote:
>>>>
>>>>> Sailesh,
>>>>> If one would expect to fill out the form one person at a time, would
>>>>> the default table layout (not taking into consideration focus order) not
>>>>> violate 1.3.2? After all, the programmatically determined reading order
>>>>> would read the cells of the table row by row, not person by person. If so,
>>>>> then this is not a sufficient technique.
>>>>> We must then conclude that there is no violation of 1.3.2, and the
>>>>> author's tabindexing is only a preference, in which a case this technique is
>>>>> totally irrelevant.
>>>>> Either way, there is a problem.
>>>>>
>>>>> On Mon, Aug 15, 2011 at 6:07 AM, Loretta Guarino Reid <
>>>>> lorettaguarino@google.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Aug 14, 2011 at 8:03 PM, Sailesh Panchang <
>>>>>> spanchang02@yahoo.com> wrote:
>>>>>>
>>>>>>> Loretta,
>>>>>>> In principle, if you content:
>>>>>>> >But the use of H4 is not required for SC 2.4.3...
>>>>>>> Then why is it listed as a sufficient technique?
>>>>>>>
>>>>>>
>>>>>> Because it is sufficient. You may use it, but you may use some other
>>>>>> sufficient technique.
>>>>>>
>>>>>>
>>>>>>> Adam,
>>>>>>> Well in that example of groom and bride, without tabindex, one may
>>>>>>> content that reading order is meaningful. But if one navigates across fields
>>>>>>> row-wise, it does affect meaning or operation. As I said in my last email,
>>>>>>> the intent is not to compare first names but actually enter data into a
>>>>>>> form. I imagine most would want to be done with data for one person then
>>>>>>>  input data for the next. While filling out paper forms too,I'd complete the
>>>>>>> form for person#1 and then person#2 and not fill out first name for person#1
>>>>>>> then jump to form for the other chap and fill out his first name. That is
>>>>>>> not logical. On a Web page the fields may be placed next to each other
>>>>>>> visually but they are meant to be navigated "logically" for person#1 and
>>>>>>> then #2. It is not the author's choice or reading  order... the author is
>>>>>>> constrained by layout / design and must use tabindex (h4) to ensure
>>>>>>> navigation does not affect operation.
>>>>>>> Sailesh
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>