[Irl-dean] HTML Question - Forms, labels and table based layouts

[Joshue O Connor]

Hi Barry,

> Just before this thread dies completely, can I just log that -
> perhaps contrary to what others have said - I *do* consider that
> there are situations in which it is appropriate to structure a
> form using a table[...]  In particular, where what
> one is dealing with is, semantically, an array of form controls,
> then I think this may be the most appropriate solution. 

It depends on your semantic perspective I guess :-)

I have to disagree. My reasons being (in no particular order of preference):

1) The relationships between the form controls and their labels are not 
programmatically determined using the method you suggest.

2) Because of this the user may not be able to understand the purpose of 
the form controls without their explicit label associations and 
therefore if the screen reader user bypasses the table (which I will 
refer to as the containing element) using the F key/E key/INSERT + F3 
functions, then the labels/information that you have provided within the 
table are no longer present.

3) This method would be useful for sighted users, but thats it.

4) Users of screen readers may not know how to interrogate data tables 
as in my experience this is something that power users do and this 
method is dependent on a certain linear browsing stlye (one item after 
another) to work at all.

>> Of course, one would want to give the user a clue that they
>> should refer to table header information for form control lables
>> in this context (perhaps in the table summary attribute?).

In once sense yes this would be very useful, but again if the user by 
passes the /container element/ then they will also by pass all this 
helpful information, hence the need for explicit programmatic 
association using label for/id combinations.

>>  Ibelieve that JAWS has, historically at least, relied on a "modal"
>> interface, where it may have been difficult to use "form mode"
>> concurrently with "table mode". As I say, I don't know if that is
>> still true, but would be interested in any clarifications.

It still does use a modal interface. The AT interacts with a 
virtualisation of the page via the OSM (Off screen model), hence the 
need for correct semantics. The user only actually interacts with the 
page directly when they wish to enter information in a form etc, hence 
"Forms mode" in JAWS. Window Eyes also has Browse Mode which IIRC is 
when it interacts with the OSM also. Some UAs don't use the OSM at all 
and interact with the DOM directly - such as HAL by Dolphin.

> Nonetheless: while I am a supporter of "practicality" I would be
> loath to recommend that anybody make their long-term markup
> design decisions based on the arbitrary vagaries of any
> particular assistive technology (no matter how widely deployed it
> might be...). 

As I am I, hence my advice to stick with explicit programmatic 
associations a la label for/id combinations.

Cheers

Josh


********************************************************************

NOTICE: The information contained in this email and any attachments 
is confidential and may be privileged.  If you are not the intended 
recipient you should not use, disclose, distribute or copy any of 
the content of it or of any attachment; you are requested to notify 
the sender immediately of your receipt of the email and then to 
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated 
by its staff are free from viruses or other contaminants.  However, 
it cannot accept any responsibility for any such which are 
transmitted.  We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email 
and any attachments are those of the author and do not necessarily 
represent the views of NCBI


********************************************************************