Re: 2.4.3, 1.3.2

Adam, you are right that the default tab order also meets SC 2.4.3. But the
use of H4 is not required for SC 2.4.3, failure to use a sufficient
technique is not failure to meet the success criterion. The HTML author who
uses no tabindex is using G59: Placing the interactive elements in an order
that follows sequences and relationships within the
content<http://www.w3.org/TR/2010/NOTE-WCAG20-TECHS-20101014/G59>
.

 H4 is included to demonstrate that SC 2.4.3 can be satisfied with a tab
order that differs from the default reading order if the order does not
affect the meaning or operability of the content. Note that it is only a
sufficient technique for 2.4.3, not for 1.3.2. In HTML, tabindex does not
change the reading order.

Loretta

On Sun, Aug 14, 2011 at 1:21 AM, adam solomon <adam.solomon2@gmail.com>wrote:

> Thanks for the response, Sailesh. I still contend that in the examples,
> tabindex need not be added to satisfy WCAG. It is only present to satisfy
> the authors personal preferences. The words "does not suffice" in the
> description really mean not sufficient for the author, but yes sufficient
> for WCAG. Take the bride and groom example. The default reading order would
> certainly be sufficient to satisfy 1.3.2 (for if not we anyway would have a
> violation of 1.3.2), so why is the author adding tabindex? The answer must
> be that he prefers to have the tab order in a different sequence for user
> convenience. Yet, even without his intervention, both 1.3.2 and 2.4.3 are
> satisfied. Thus, the examples given in H4 are not necessary to satisfy any
> success criterion. On the contrary, they simply don't create a failure. I
> always assumed that a sufficient technique is defined as one which actively
> satisfies a success criterion, such that if it were not implemented (and
> assuming no other technique was used) then there would be a failure. This
> does not seem to be the case with the examples in H4.
>
> On Sun, Aug 14, 2011 at 3:51 AM, Sailesh Panchang <spanchang02@yahoo.com>wrote:
>
>> Adam,
>> In the first example for H4, the author believes it makes better sense to
>> read the fields for the groom and then the bride and has used tabindex.
>> Sometimes, the tab order  goes to main content area and then to nav links
>> that perhaps precede it in reading order. And this may be done via tabindex.
>> Consider another scenario:
>> <div on the left>
>> Product name 1 with h tag
>> Some info
>> Learn more link
>> Price info
>> Add to cart button
>> </div>
>> <div on the right>
>> Product name 2 with h tag
>> Some info
>> Learn more link
>> Price info
>> Add to cart button
>> </div>
>> Default reading order and tab order is fine. But I have seen instances
>> where tabindex has been added that takes focus from one learn more link to
>> the next and then from one add to cart button to the next. Here focus order
>> does not match logical reading order... hence the line in h4 that saes make
>> sure the two match.
>> H4 begins with 'default order does not suffice'.
>> Rightho,
>> Sailesh Panchang
>> --- On Sat, 8/13/11, Adam Solomon <adam.solomon2@gmail.com> wrote:
>>
>>
>> From: Adam Solomon <adam.solomon2@gmail.com>
>> Subject: RE: 2.4.3, 1.3.2
>> To: "'Loretta Guarino Reid'" <lorettaguarino@google.com>
>> Cc: "'WCAG'" <w3c-wai-gl@w3.org>
>> Date: Saturday, August 13, 2011, 3:31 PM
>>
>>
>>
>>
>>
>>
>>
>>
>> Tabindex is listed as one of the techniques in
>> http://www.w3.org/WAI/GL/wiki/Techniques/HTML5 for 2.4.3, focus order.
>> Use of tabindex in html5 is basically the same as in 4, except that it
>> applies to all elements. In the html4 techniques,
>> http://www.w3.org/WAI/GL/2011/WD-WCAG20-TECHS-20110621/H4 uses
>> specifically set tabindex values as a means of fulfilling SC 2.4.3. In the
>> understanding document for 2.4.3, it states that care must be taken to make
>> sure the focus order matches the programmatically determined reading order.
>> As a result, all the examples in H4 are fairly harmless. In other words, it
>> seems that in all of the examples, there is no necessity to add tabindex
>> values to change the focus order, rather a slight preference by the author
>> to do so. The reason for this is that inherently, where there is a necessity
>> to add tabindex values to straighten out the tab order, we must assume that
>> the programmatically determined reading order is incorrect,
>>  otherwise it wouldn’t be necessary to add those values in the first
>> place. The point of all this is that in all the examples even if the author
>> did not choose to add tabindex values, the page would still fulfill 2.4.3. I
>> can’t think of a case where adding tabindex is actually fulfilling 2.4.3,
>> except in a case where only sighted users were viewing the page and the only
>> thing that counted was the tab order, and not the programmatically
>> determined reading order. Is H4 really a sufficient technique for 2.4.3?
>>
>>
>> From: Loretta Guarino Reid [mailto:lorettaguarino@google.com]
>> Sent: Tuesday, August 02, 2011 4:43 PM
>> To: adam solomon
>> Cc: WCAG
>> Subject: Re: 2.4.3, 1.3.2
>>
>> Andrew should weigh in on this, but I believe this is the way things work
>> in Flash, that tabindex can be used to control the reading order of all the
>> content, not just interactive content.
>>
>> Using tabindex in HTML is not a sufficient technique for 1.3.2.
>>
>> On Tue, Aug 2, 2011 at 2:03 AM, adam solomon <adam.solomon2@gmail.com>
>> wrote:
>>
>> We have Using tabindex in flash as a sufficient technique in 2.4.3 and
>> 1.3.2. 1.3.2 stipulates meaningful sequence to be programmatically
>> determined. Can someone explain how tabindex facilitates this? Tabindex will
>> never fix a bad sequence for screen readers, so how can it satisfy 1.3.2?
>>
>>
>>
>