RE: 08 August 2006 Agenda

My only suggestion on this is that you be careful not to adopt a "let's
help them by making it easy for them" mentality, which can be
patronizing.  To put it bluntly, I make my customers get off their tails
and learn their AT or they don't use it.  Blind people deserve the
respect of being held accountable for using their AT.  The phrase,  

The sentence "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,"
comes very close to being a bit paternalistic.

Don



-----Original Message-----
From: Ben Caldwell [mailto:caldwell@trace.wisc.edu] 
Sent: Tuesday, August 08, 2006 6:36 PM
To: Bailey, Bruce
Cc: public-wcag-teama@w3.org; Barrett, Don
Subject: 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 Friday, 11 August 2006 14:35:52 UTC