Re: is SCOPE sufficient? - a test based on WCAG2 techniques example

aloha, marghanita!

the form is non-functional -- it is 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 were simply to differentiate visually a pseudo-
fieldset (and actual one not being valid in a table or vice versa)

green background was for the 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 was to indicate 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") indicating ownership of the column by the "Bride"

the purple background was to provide a visual pseudo-label for 
both input fields, 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 posted the test using scope alone as 
a programmatic binding -- i am in the midst of finalizing comparative
versions of the same example from WCAG 2.0's techniques document, using:

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 texts 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 need to archive and post the URIs for the 
comparative tests -- the one sure garuntee 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

i hope this clarifies the point of the exercise -- any and all feedback
is welcome...  i hope to post the URIs of the 4 supplemental tests 
to public-html as soon as they are archived in www-archive so that they
can be referenced reliably...

gregory.
---------------------------------------------------------------------
A conclusion is simply the place where someone got tired of thinking.
                                                      -- Arthur Bloc
---------------------------------------------------------------------
   Gregory J. Rosmaita - oedipus@hicom.net AND gregory@ubats.org
        Camera Obscura: http://www.hicom.net/~oedipus/
---------------------------------------------------------------------

---------- Original Message -----------
From: Marghanita da Cruz <marghanita@ramin.com.au>
To: "Gregory J. Rosmaita" <oedipus@hicom.net>
Cc: public-html@w3.org
Sent: Thu, 20 Sep 2007 08:54:02 +1000
Subject: Re: is SCOPE sufficient? - a test based on WCAG2 techniques 
example

> Gregory J. Rosmaita wrote:
> > aloha!
> > 
> > a few days ago, i archived the following explanatory emessage with an 
> > attached test file in a post archived at:
> > 
> > http://lists.w3.org/Archives/Public/www-archive/2007Sep/0056.html
> > 
> > the test file is archived at:
> > 
> > http://lists.w3.org/Archives/Public/www-archive/2007Sep/att-0056/form-
in-
> > table-uses-tabindex-and-scope.html
> <snip>
> Hi Gregory (note message not copied to wai-xtech@w3.org as I am 
> not on that list),
> 
> Following up from the screenshot, I sent to you offlist - did 
> you intend for the main/column header to extend across the row 
> headers? Or does the green indicate that you intended "search 
> results to appear at the top, above the first column/row labels.
> 
> My own strawpolling of browser support for XHTML/HTML revealed some
> unexpected variability on how different browsers handle the Alt Text.
> I have had no first hand experience of Assistive Technologies 
> and would be interested to know if these variations matter?
> 
> Screenshots for Konquerer/Firefox/Iceweazel (Linux/MSWin)/IE are 
> at <http://www.ramin.com.au/linux/html-strawpolls.shtml>
> 
> I would like to add screenshots of Opera and Safari. Firefox 
> seems pretty consistent across platforms.
> 
> Marghanita
> -- 
> Marghanita da Cruz
> http://www.ramin.com.au
> Phone: (+61)0414 869202
------- End of Original Message -------

Received on Thursday, 20 September 2007 00:33:37 UTC