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

[Joshue O Connor]

Barry McMullin wrote:
> I probably should not keep babbling to myself, but ... I have now
> found one person who has proposed a solution for (more or less)
> this situation. It is Jim Thatcher, and is contained here:
> 
> <http://www.jimthatcher.com/webcourse8.htm>

Good stuff. We were, I think to some degree at cross purposes in some of 
our correspondence but the discussion is interesting nonetheless. Sorry 
I have not had time yet to look at your example in detail but will do. I 
think you may also be interested in WAI-ARIA and the use of (in 
particular the aria-labeled by and aria-described by properties) as they 
provide a means of marking up content and describing relationships in a 
more flexible manner than existing markup. [1] [2] [3] [4]

They provide a kind of generic semantic "bridge" to define 
relationships, as well as other things. Gez has written extensively 
about it and is someone who I would consider to have expert knowledge in 
this area ,though he may well deny this, but don't listen to him :-) [5] [6]

Note also that WAI-ARIA allows developers to do things *right now*, that 
HTML 5 promises to *possibly* do in about 5 years. IE 8 has also 
included support for some of WAI-ARIA, which is a big step forward.[7]

> Basically the suggestion is that, if there are
> specific reasons why it is difficult to label form controls using
> the <label> element, then the title attribute (on the form
> control itself) can be used instead. 

Yes, this would work and be very practical in particular for screen 
reader users as the contents of the form elements title attribute is 
announced when the element has focus. Please note that WCAG 1.0 (12.4) 
suggests that even a single form element should have an appropriate 
label, though IMO this may not always be really necessary but to be 
compliant etc you should apply a label as this is indicative of best 
practice in general. [8]

> Table interaction
> is not only about accessing headers.

Absolutely, but they are an important part of accessible table markup 
and often act as a hook for user agent heuristics which are often still 
applied very badly. There are more sophisticated elements that can be 
used such as the scope attribute instead of headers and id combinations 
but. There is also summary, axis, scope, and abbr elements that can be 
used for making complex tables more accessible. Gez also wrote an 
excellent "Complex Table Inspector" tool. [9] [10]

> I should note that Jim Thatcher's discussion/proposal (and
> perhaps Josh's perspective also?) are significantly influenced by
> the behaviour of one (?) particular screen reader:

FWIW I consider a wide range of AT and use cases. The truth is that many 
of them often poorly implement the algorithms anyway which make the 
authors life harder.

>> > One might hope that table navigation [...] with a screen reader
>> > would automatically speak the properly marked up table
>> > headers. That would be true when navigating the table in "web
>> > mode" or tables reading mode. But a user is going to be
>> > listening to these controls in forms mode, not in table reading
>> > mode, and in this situation the table headers are not spoken.
> 
> Now I am not saying we should simply ignore the behaviour of
> specific user agents or assistive technologies (some of you will
> know I've got mired in a separate discussion on that topic on the
> GAWDS list...).  But there are definitely long term problems that
> can arise from going down that route; so if *that* is the basis
> for particular advice on "accessible content design" then it's
> important to make that explicit (not least so that AT developers
> can recognise deficiencies that it is *their* responsibility to
> address, and so that content developers will be able to recognise
> if or when the technology limitations giving rise to particular
> advice no longer prevail).

Yes. This is where we cross over in "User Agent Issue" territory. We 
could have perfect markup/solutions but if the algorithms and heuristics 
that the vendors design are poor then the output will also be poor. I 
guess, we could get into star gazing but we need to be able to suggest 
real solutions for todays user experience. This is partly why WAI-ARIA 
is so interesting.

Cheers

Josh


[1] http://www.w3.org/WAI/intro/aria
[2] http://www.w3.org/TR/wai-aria-roadmap/
[3] http://www.w3.org/TR/wai-aria-practices/
[4] http://www.w3.org/TR/2006/WD-aria-state-20060926/
[5] http://juicystudio.com/article/wai-aria-in-html.php
[6] http://juicystudio.com/article/wai-aria-live-regions.php
[7] 
http://www.ibm.com/developerworks/blogs/page/schwer?entry=microsoft_announces_support_for_wai
[8] http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-associate-labels
[9] http://cita.disability.uiuc.edu/html-best-practices/nav/cdtables.php
[10] http://juicystudio.com/article/complextableinspector.php

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

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


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