Re: 08 August 2006 Agenda

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.