Re: 08 August 2006 Agenda

Hi Bruce,

I'm not trying to argue that those who use certain screen readers will 
not be able to figure out some of the table/form examples you've 
provided. However, why encourage (or create an exception for) these 
situations when the end result is that using the <label> element or 
title attribute on these examples makes them more accessible to more 
users? It seems to me that creating an exception here both increases the 
cognitive load on the user and increases the number of keystrokes 
necessary for a user to successfully fill out the form.

I agree that some additional testing would be useful here so that we can 
more clearly understand where the barriers are. However, my experience 
with screen reader users and the problems they most often encounter 
related to forms is that they often miss information contained within 
the form element entirely (ex. instructions or links to information 
relevant to filling out the form). Sometimes this is a result of 
inexperience with their screen readers, sometimes due to quirks with the 
user agents, but I think that most often it is because the techniques we 
currently list as sufficient weren't followed.

Let's talk more about this at next week's Team A meeting. I'd like to do 
some digging on this in the meantime and get a better sense for where 
support for this across various user agents is at this point in time.

-Ben


Bailey, Bruce wrote:
> I have been using screen readers for almost twenty years now.  Plenty of that involves teaching and hardened real world experience.  It is only in the last few years that I have come to appreciate the subtlety of some of my misunderstandings.
> 
> I think we need to do some user testing before making these kind of assumptions.  I am deeply concerned we are asserting as obstacles things which are not actual barriers.  I have come to believe that the reliance on table structure to associate form controls with their labels is in wide use and should be an acceptable sufficient technique for meeting SC 1.3.1. 
> 
> The quote below comes from my esteemed colleague Don Barrett, his name will be familiar to some.  The term "20/20 conceit" was coined by Doug Wakefield.  Name withheld to protect the guilty!  Don is commenting on the very 3x3 form I sent to the list the other day.  The 2x2 example we (the few of us who do web testing for ED) have also considered as a group, and judge to acceptable, at least by the 508 1194.22(n) standard.  The same is true for the new sample attached.  I would be pleased to vet the three examples to a larger group.
> 
> <blockquote>
> [PERSON] has 20/20 conceit in that he supposes to know how screen reader users use their screen readers.  His notion of ignoring the arrow keys and using tab or letter navigation keys is false and extremely presumptuous.
> 
> Also, his assertion that people fill out forms in forms mode is a true sign of inexperience and a lack of understanding of what forms mode is all about.  Forms mode, as I understand it, has but one purpose:  to turn off the screen reader buffer so an individual can directly interact with IE controls.  There is nothing about forms mode that increases navigability, and people who really know their screen readers, don't necessarily have to stay in forms mode unless of course they want to do so.
> </blockquote>
> 
> Please consider the attached survey example.  It would be onerous to expect the author to add thirty title long title attributes to each of the radio buttons.  Such additional forced verbosity would be counter productive to the average JAWS user.  The current version of WindowEyes does not even support the title attribute, so it would not be helpful to that audience.
> 
> WCAG 2.0 currently relegates robust noframe content and scaleable fonts to advisory techniques, yet requires superfluous use of title for forms making good use of simple two dimensional tables?
> 
> P.S., I will have something on FONTS soon.
> 
> 
> -----Original Message-----
> From: public-wcag-teama-request@w3.org
> [mailto:public-wcag-teama-request@w3.org] On Behalf Of Ben Caldwell
> Sent: Tuesday, August 08, 2006 10:26 AM
> To: public-wcag-teama@w3.org
> Subject: Re: 08 August 2006 Agenda
> 
> Hi Bruce,
> 
> I'm not sure I would agree that the example you've provided is 
> accessible. Many screen readers will (by default) jump into forms mode 
> as soon as the first field of a form receives focus. When this happens 
> (and  I'm not suggesting that this is what _should_ happen), my 
> understanding is that the only items that will be read in this mode are 
> label elements and title attributes.
> 
> Basically, what you're describing is a scenario where AT is forced to 
> guess about which text goes with which form field and while this example 
> happens to linearize correctly. There are many examples, however that 
> don't linearize as well and though AT has evolved such that it's better 
> at guessing today than it was 5 years ago, I don't think we want to get 
> into making exceptions in WCAG 2.0 for these algorithms.
> 
> -Ben
> 
> 
> Bailey, Bruce wrote:
>> My most sincere regrets.  I forgot about a meeting I have with a certain other standards body.
>>
>> Attached is a very short form that is not WCAG 2.0 single A compliant, but perfectly accessible.  It could be much longer, but the layout is so straightforward, it is hard to credibly argue that it represents a barrier.
>>
>> This is less a challenge for the 508 folks too, since something like this *is* permitted by the wording of 1194.22(n).  One will note, however, that this is drawn from a *counter* example in the 508 guide to the standard.  The AT has much improved since that was written.
>>
>> However, I am at a loss as to how to word a technique that permits linearization and position to substitute, under certain conditions, for LABEL.
>>
>> I have a just slightly more complicated survey example prepared.  I am conducting some additional real world test before I offer it as example that should be permissible.
>>
>> ------------------------------------------------------------------------
>>
>>
>>   Survey form in Table
>>
>> In general, how satisfied are you with the way the information is 
>> /presented/?
>>
>> Please rate your experiences with our web site in the categories 
>> listed. Category 	Very
>> Satisfied 	Satisfied 	Neither Satisfied
>> nor Dissatisfied 	Dissatisfied 	Very
>> Dissatisfied 	Don't Use / Don't know /
>> Not Applicable
>> clarity of the writing (readability, ease of interpretation) 
>>   	  	  	  	  	 
>> layout of the material 	  	  	  	  	  	 
>> clarity of the tables and charts 	  	  	  	  	  	 
>> amount of graphics (too few, too many) 	  	  	  	  	  	 
>> clarity of the graphics 	  	  	  	  	  	 
>>


-- 
Ben Caldwell | <caldwell@trace.wisc.edu>
Trace Research and Development Center <http://trace.wisc.edu>

Received on Tuesday, 8 August 2006 22:34:21 UTC