4 tests of form controls in layout tables with author-defined tab navigation order

the 4 attached forms are all non-submittable -- they are intended to test 
support for navigational and contextual markup by using sample form text,
whose layout is controlled by a table, and whose tab navigation sequence 
has been redefined by the author...

the color choices simply differentiate visually a pseudo-fieldset (an 
actual one not being valid in a table or vice versa)

the green background is used for a pseudo-legend (signifying that 
these fields belong together for X by Y purpose -- X being "Search 
for Marriage Results" and Y being "Search Criteria"

the blue visually indicates ownership of the column by the "Groom"

the pink/peach (i approximated the hexidecimal values in my head,
and i've heard conflicting reports as to the background color 
behind "Bride") visually indicates ownership of the column by the 
"Bride"

the purple background provides a visual pseudo-label for both input 
fields in the 2 column table, as it is not possible to either set an 
implicit label that contains both TD elements, nor would it be possible 
(in HTML 4.01/XHTML 1.0, at least) to assign identical ID values for 
more than one INPUT element -- you can point multiple labels to a 
single form control, but you can't point a single label at multiple
form controls, and support for multiple labels is very poor on both
the user agent and the assistive technology fronts...

ideally, the pseudo-fieldset would be an actual fieldset, the 
pseudo-legend an actual legend for the grouping as a whole, and 
multiple labels would point at each input field, explicitly binding 
each input field to the row and column header text a sighted user 
visually associates with the form control...

to overcome these barriers, i earlier posted the test using scope alone 
as a programmatic binding -- consult:

http://lists.w3.org/Archives/Public/www-archive/2007Sep/0056.html

for an explanation of the initial test, and:

http://lists.w3.org/Archives/Public/www-archive/2007Sep/att-0056/form-in-
table-uses-tabindex-and-scope.html

to access the test itself...

the 4 attachments to this post uses the same example from the same draft 
of the techniques document for WCAG 2.0:

http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/#H4-ex1

but with various combinations of explicit binding mechanisms:

1. tabindex and headers/id attributes;

2. tabindex and headers/id attributes supplemented by the axis attribute;

3. tabindex and headers/id attributes supplemented by the scope attribute;

4. tabindex and title alone

the point of these tests is simple:  the author of the table-ized form
wants to set the tab navigation order so that one tab navigates the 
table not by moving from cell to cell, but down one column and then 
down the second colum...  since this is an "unexpected" and author-
defined behavior, rather than the expected behavior of tab navigation 
in a user agent, it is extremely important to provide a programmatic 
binding so that the pseudo-labels for both column and row can be 
communicated to a user who cannot perceive the unorthodox tab navigation 
order as that user tabs through the table-ized form...

unfortunately, support for multiple headers values -- a space delimited 
list -- is, as far as i can tell with the tools at my disposal, as 
poorly supported as are multiple labels which point to a single form 
control, which is why i have archived and will post the URIs for the 
comparative tests to the HTML working group mailing list and the wai-
xtech list when this post is archived...

the one test which is sure to work in the vast majority of cases, is the 
use of explicit individualized title text for each individual form 
control, but that is, by far, the most labor intensive and least 
mechanized means of doing so, as unique title text needs to be defined 
for EACH input element, whereas an automatic headers/id association could 
be achieved through a macro in an authoring tool, or by native support 
for such associations built into an authoring tool...

the other complicating factor i am attempting to illustrate with these
sample pages is that markup that is defined for table contextualization
may not be available if a user has to invoke a "forms mode" in order to 
interact with, and obtain state information about, individual form 
controls, which may block the programmatic bindings defined for the form
element as a component of a TABLE -- for example, if i listen to the 
page in its entirety, i hear the "summary" defined for the table spoken;
when i invoke forms mode to "jump to the first form control" or to "list
form controls" the summary defined for the table is not announced, nor 
does querying the cell as one would do in a data table, does not expose
the row and column bindings, but only those defined for the form control
as a form control...  this is part of an attempt to study conflicting 
explicit association patterns, as addressed in the wiki page:

http://esw.w3.org/topic/HTML/ExplicitAssociationPatterns

especially the last example of Explicit Association Patterns defined in
HTML 4.01, which illustrates a conflict of title information, both of 
which is potentially useful/necessary for a user to fully comprehend 
the purpose of the link and the expansion of an ACRONYM contained in 
the hyperlink text...

the direct URI to the example i described above is very long and will 
probably wrap and break in some email clients, as well as in the archive,
but it is:

http://esw.w3.org/topic/HTML/ExplicitAssociationPatterns#head-
cc0ec8966aa57e0028c9f4780e31159755534118

the original document source which forms the basis of all five documents
can be found at:

http://esw.w3.org/topic/HTML/ExplicitAssociationPatterns#head-
5863a518c17510a69b5f858ae1655e8b25db3246

gregory.
-------------------------------------------------------
lex parsimoniae:
  * entia non sunt multiplicanda praeter necessitatem.
-------------------------------------------------------
the law of succinctness:
  * entities should not be multiplied beyond necessity.
-------------------------------------------------------
Gregory J. Rosmaita, oedipus@hicom.net
         Camera Obscura: http://www.hicom.net/~oedipus/
-------------------------------------------------------