Re: 2.4.3, 1.3.2

Understood. But I still take issue with this for the following reason: While
we have endlessly stressed that no single technique is necessary to avoid a
failure, nevertheless a technique which in effect does nothing to promote
the fulfillment of a success criterion is really a failure in reverse. In
other words, H4 is simply saying to authors: If you are going to change the
focus order, don't do it in such a way as to break the reading order and
violate 1.3.2. That is inherently different from a technique which, for
instance, tells an author to markup tabular data in a table element. In such
a case, without the table markup, there exists some deficiency which needs
to be corrected. To be sure, other techniques exists which might replace the
need for table markup, but something should be done. In H4, on the other
hand, all the examples deal in cases where nothing needs to be done - as is,
we are satisfying both 2.4.3 and 1.3.2. It is just that the author is not
satisfied with the default tab order, and so we advise him to change it in a
way which won't contradict the reading order. Essentially, this is the
failure F44, which dictates that tabindex not break the reading order. If we
have such techniques (which are more or less simply tips on how not to fail
a success criterion and are wrapped as sufficient techniques for ease of
use) then I have no problem with this one as well. But if not, then this
technique is unnecessary.

On Sun, Aug 14, 2011 at 5:28 PM, Loretta Guarino Reid <
lorettaguarino@google.com> wrote:

> 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?
>>>
>>>
>>>
>>
>