Re: 2.4.3, 1.3.2

Hello Adam,
Well I do agree with you re. what is a sufficient technique.
Right, in the groom and bride example one can tab to both first name fields and then to 2 last name fields ... they are labelled etc. But typically one reads the info for an entity and then the next unless the objective is to compare first names or compare ages... then one would want a data table representation of the data. Here it is a case of a table being used for layout. If I am entering data from a paper application on to the Web page, I expect to step through the info for a person then the next. So reading it row wise is sort of illogical though it makes sense. And that is what the author is doing via tabindex.
 On the other hand if one used tabindex in the  div- example in my email about 2 products such that the tab went from one learn more link to the next, then that would break logical reading order. The purpose of the link would be clear from context but tab order is not proper don't you think? ... That would be a failure example.
Rightho,
Sailesh

 
--- On Sun, 8/14/11, adam solomon <adam.solomon2@gmail.com> wrote:


From: adam solomon <adam.solomon2@gmail.com>
Subject: Re: 2.4.3, 1.3.2
To: "Sailesh Panchang" <spanchang02@yahoo.com>, "WCAG" <w3c-wai-gl@w3.org>
Date: Sunday, August 14, 2011, 4:21 AM



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?

Received on Sunday, 14 August 2011 13:40:43 UTC