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

[Joshue O Connor]

Barry McMullin wrote:
> Ah, excellent ... we were overdue for a good game of Josh-Barry
> geek-ping-pong (grin!).

LOL

>> 1) The relationships between the form controls and their labels are not
>> programmatically determined using the method you suggest.
> 
> They aren't? In what sense is the relationship between a table
> cell and its header(s) any less "programmatically determined"
> than the relationship between a form control and a label element?

Looking at either domain in isolation they are not. However in this use 
case the boundaries are blurred and there are some important 
distinctions between the two. I'll take the second issue first. Screen 
reader users can infer meaning about the purpose of the control, or some 
functionality or requirement such as a field being required etc from the 
author marking up content using label for/id combinations. A screen 
reader user may not be able so if these elements are  absent. So within 
the context of how to do forms (which is what this thread is about) they 
need to be marked up correctly and conform to the HTML specification. [1]

Please note: as per the HTML 4 specification on the issue of using 
labels and tables:

"Note that this technique cannot be used when a table is being used for 
layout, with the label in one cell and its associated control in another 
cell." [2]

As for the relationship between tabular data cells, other mark up 
techniques exists that can describe the content to the User Agent in a 
perfectly satisfactory manner. If you wish to describe form elements as 
tabular data because you place then in a table then thats fine, but I 
wouldn't. [3]

Some good advice for accessible forms. [4] [5]

 >> 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.
 >
 > Hang on ... you are saying to not use a table to mark up
 > information having genuine "tabular" semantic relationships
 > because some users might choose to "bypass the table"?  On that
 > logic one would never use tabular markup at all...

Not at all. I am making the point that the table should not really be 
used at all to hold individual parts of a complex form and *describe* 
the relationship which would be achieve more /correctly/ using label 
for/id combinations. The right tool for the right job really. Use <divs> 
as holders, style the form with CSS and use <legend> and <fieldsets> 
elements where appropriate. The reason I made this point is that you 
cannot create semantically correct relationships between tabular content 
and form elements using a hodge podge of table mark up and form markup.

>>> 3) This method would be useful for sighted users, but thats it.
>> 
>> Don't quite get that.

The use of table headers to say "In this column you will find the form 
label" and "In this column you will find the form control" may work 
visually but it is *not correct* without the underlying markup 
(label/for etc) for the form controls. So my point is, this kind of 
thing may fly for a sighted user who can easily see which column relates 
to which control. Having said that, a screen reader user may interrogate 
the table and try and figure out what is what, and what does what, and 
they *may* successfully be able to figure it out, but its not an ideal 
approach at all IMO.

>>> 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.
>> 
>> Again, this is simply advocating not using tabular markup for its
>> intended semantic purpose (data tables) [...]

No it's not. I would never say that. What I am saying is:

1) that I don't consider form controls etc to be strictly tabular data 
for a start, just because you choose to put them in a table.
2) You cannot use table semantics to imply the correct relationship to a 
User Agent such as a screen reader that will create a good user 
experience for a blind user.

>>  Butthe solution to that is surely not to give up on table mark up
>> where it is sematically appropriate.

Where it is appropriate it should, of course, be used.

Sin e (or "Ping" as Bearla)

Josh


[1] http://www.w3.org/TR/html401/interact/forms.html
[2] http://www.w3.org/TR/html401/interact/forms.html#h-17.9.1
[3] http://www.webaim.org/techniques/tables/
[4] 
http://www.accessit.nda.ie/web-resources/guidance/designers/forms/des-5.1
[5] http://www.webaim.org/techniques/forms/



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

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


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