RE: labeling controls in tabularized forms (was Re: Proposal for fixing label)

aloha, jim!

my concern is not merely what is going to work now -- although that is a
very large concern of mine, and one in which i have a vested interest --
but discovering precisely which of the features introduced into HTML4/XHTML1 
to support interoperability, internationalization, and accessibility are not 
being supported by AT vendors, even though the means to do so is (ostensively) 
available to ATs via third party software (read: user agent) 

there is no excuse for any AT or "specialized" UA not to support fieldset,
legend, and label -- not to mention OPTGROUP, SUMMARY, ABBR, ACRONYM,
SCOPE, and AXIS, to name but a few...  so, what can we do to encourage
support for such elements and attributes?  we need to discover what works
now; what should work, but doesn't; and what is available via various user
agents and ATs, and channel that feedback to both UA and AT developers,
which explains the proliferation of test pages which i've been posting
recently... 

why should AT vendors add support for a hack, when superior and standard
methods exist and, in an apparently unknown number of instances, are
supported by "mainstream" applications?  rather than expending precious
developer time on exposing TITLE on form controls, i'd prefer AT
developers work on supporting TITLE where it is explicitly specified as
providing a textual equivalent, such as when it is used in conjunction
with the HR element -- when "title" was added as an attribute for HR at
the dawn of the WAI, i thought that the days of using a graphical
separator, for which orientational ALT text had been defined (such as
ALT="The Fine Print: Please Read This Disclaimer at Least Once"  or
ALT="Begin Printed Page 86") were over...  why don't i have the option to
set my AT to expose the content of ABBR and ACRONYM if i so
desire--automatically or on demand? (in the latter case, alerting me
through an earcon, such as a pitch change or short beep, that an expansion
is available)

so, i implore all members of the WAI-IG to please take a look, listen,
and/or feel to the test pages attached to my post, and to provide feedback
via the wai-xtech list (wai-xtech@w3.org)

thanks to the mail archives, the test pages have stable (if unwieldy) 
URIs:

1. Tabular Forms Employing LABEL (3 Forms on One Page)
<http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/att-0611/01-tabular_forms_using_label.html>

2. Tabular Form Using LABEL & ACCESSKEY
<http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/att-0611/02-tabular_forms_using_label2.html>

3. Tabular Form Using Only TITLE and ALT, 1 (ALT for INPUT; TITLE for SELECT)
<http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/att-0611/03-tabular_form_using_title_and_alt.html>

4. Tabular Form Using Only TITLE and ALT, 2 (ACCESSKEY indicated using 
deprecated U element, rather than span as in previous form)
<http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/att-0611/04-tabular_form_using_title_and_alt2.html>

5. Tabular Form Using LABEL, ACCESSKEY, TITLE, & ALT  (The Hedged Bet Form)
<http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/att-0611/05-tabular_form_using_label_and_alt.html>

and, i employ AT and "mainstream" developers alike not only to keep
abreast of evolution of the User Agent Accessibility Guidelines 
  (Last Call Draft: http://www.w3.org/TR/uaag10
  Latest WG Draft: http://www.w3.org/WAI/UA/uaag10)
and the HTML4 Accessibility Note-in-Development, located at:
  http://www.w3.org/WAI/References/HTML4-access.html

if we're going to "fix" things, let's "do it right", by pushing support
for what is specified, rather than what works for certain applications
under certain circumstances...  yes, TITLE is a generic attribute that can
be appended to almost everything in the BODY of an HTML document, and i 
agree that ATs should recognize and use it where necessary (or when configured 
by a user to do so), but where more robust solutions have been provided 
(LABEL, for example, has the advantage of being a container, which means that 
it, unlike TITLE can contain marked-up text) 

my point is that ATs should react to the standard markup which has been
explicitly defined to increase accessibility, before being trained to
recognize half-measures and kludges, as the latter not only leads to the
entrenchment of kludges, but often proves a formidable impediment to
change, on the part of both software and web-content developers... as a
webmonster once emailed me, quote Why shouldn't I use NOFRAMES to push
people to upgrade their browsers?  Lynx provides access to my site whether
or not I use NOFRAMES in the manner you suggested, so I fail to see why I
shouldn't use them to encourage visitors to upgrade their browsers, so
that they can more fully experience the richness of our site unquote

gregory.
------------------------------------------------------------------------
CARNIVOROUS, adj.  Addicted to the cruelty of devouring the timorous 
vegetarian, his heirs and assigns.
	                    --  Ambrose Bierce, _The Devil's Dictionary_
------------------------------------------------------------------------
Gregory J. Rosmaita, oedipus@hicom.net
                Camera Obscura: http://www.hicom.net/~oedipus/index.html
------------------------------------------------------------------------

Jim Thatcher wrote:
> Just a clarification of the example. The fact that my example does not speak 
> is sort of the problem. Today Window-Eyes will speak all the titles of those 
> input cells. I have been told that JFW will support titles on input elements 
> soon; same for HPR. The point is that you can capture the intended labeling 
> with titles. Phill's proposed change to LABEL (or some variation) is great, 
> but that is a long term solution. We need a solution today for forms with 
> complex layouts - not necessarily the simple rectangle of the example.

Received on Tuesday, 5 June 2001 18:03:15 UTC