Table Structure for Form Elements (was RE: 08 August 2006 Agenda)

Thanks Ben for your well considered reply.  I acknowledge that what I am proposing is relatively radical and I therefore bear the burden of making the case.  Constructive feedback is necessary for this notion to get tempered into an acceptable technique. 

Don and another gentleman here, Rajiv Shah, in addition to providing guidance to web developers, also provide the end-user customer support.  While Don and Rajiv are classic power users (Rajiv used to work for Freedom Scientific, and is still a beta tester for GW Micro) the ED employees they support definitely are not.

I am less confident of putting a table-based technique up against LABEL, but the problem with the latter is that it is not suitable when a field needs to make reference to two or more identifiers.

I do believe that relying on table structure is equal or better than using the title attribute.  I do not agree with the characterization that title is more accessible.

I regard the use of title to be a kind of hack.  Rather than relying on the inherent structure that is already present (By the way, do we have uses of title that are not based in tables?), we are asking the content author to provide redundant (albeit invisible) information.  It is obviously more reliable for the screen reader and end-user to depend on information that, by default, is already present.  This is not like alt tags where there is no other way to get the textual equivalent.

Consider a middle part from the survey example.  Relying on the table structure results in this code:

<td> <input type="radio" name="prestab" value="3"></td>

If dropped into the middle of the form, there is a hot key that will speak the full context and provide both row and column headers.  If going down a column, only the changing row heading need be spoken.  If going across a row, only the changing column heading is spoken.  I would argue that this is *more* accessible than the title approach because the end-user is given more control and the prompts are directly tied to how the end-user chooses to interact with the form fields.

Consider the corresponding title technique:

<td> <input type="radio" name="prestab" value="3 title="clarity of the tables and chart, neither satisfied nor dissatisfied"></td>

This is too verbose for almost all end-users.  I would also argue that it is not a reasonable expectation to impose on content author.  This is just one cell in one row.  It is not uncommon for a survey to have hundreds of radio buttons or check boxes.  From the end-user perspective, the additional forced verbosity is especially unhelpful when trying to navigate from column to column title attribute forces one to keep hearing the row heading again and again.

On top of this all, title is *not* well supported by WindowEyes!

I don't see how either relying on table structure, nor the use of title, helps address the issue of end-users missing instructions and cues.

I look forward to the results of your inquiries for where  support for this across various user agents is at this point in time.  I may vet this to a larger audience as well.  After this post, I do intend to sit on my hands and wait for the next Team A call rather than spend much more time on the issue via email.

Thanks again.


-----Original Message-----
From:	Ben Caldwell [mailto:caldwell@trace.wisc.edu]
Sent:	Tue 8/8/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