Re: HEADERS, FOR whom - any ID?

I know I'm coming late to this debate, but 
there's another aspect of the FOR/ID pair that I have not seen represented.

I'd like to see a different tactic in this 
debate.  Can someone explain what the downside to 
including them is?  If some would rather not use 
them, I have not seen anything that would require 
them to do so, and the rest of us can continue to 
use them in the manner for which I believe they were intended.

Most of the complaints I've seen claim that these 
"accommodations" are just for one segment of the 
population (i.e., people with visual 
impairments).  The FOR/ID implementation is also 
a great help to people without fine motor 
control, as it increases the target area in which they can click.

There are other considerations as well.  While 
the comments of some in this thread seem to 
indicate they can afford to dismiss those with 
disabilities, those of who work in or for the 
public sector cannot.  We have laws and policies 
that make it imperative that our web sites be 
accessible to as wide a user population as 
possible.  I can comment in terms of New York 
State's (U.S.) policy 
<http://www.oft.state.ny.us/policy/p04-002/index.htm> 
and mandatory technology standard 
<http://www.oft.state.ny.us/policy/s04-001/index.htm>.

Specifically, as regards tables:

7.1 All tables are required to have a summary attribute.

7.2 Tables used solely for formatting, will 
specify that purpose using a summary attribute 
(e.g., summary="format" or summary="for layout only").

7.3 Tables with tabular data will use the scope 
attribute to identify both horizontal and vertical headings.

7.4 Row and column headers will be identified for data tables.

Much of the discussion I've read on deprecating 
headers has inferred that the scope element can 
substitute.  I don't believe that scope is 
supported in aural user agents in the same way 
that headers/id information is.  The most useful 
example I've found of using headers/id is for 
extremely dense tables of such size that 
reiteration of row and column headers is 
necessary to place the information in context.

And as regards form input elements:

13.1 On-line forms will allow people using 
assistive technology devices to access the 
information, field elements, and functionality 
required for completion and submission of the 
form, including all directions and cues.

13.2 A label element will be used for all form 
controls that do not have implicit labels.

13.3 Forms elements will be in logical tab order.

I hope that in the process of deciding what to do 
with the headers and for attributes, the 
requirements of public sector web development are taken into consideration.

Debi Orton/oradnio@gmail.com



At 09:51 PM 8/4/2007, you wrote:

>On 2007-08-04 16:56:41 +0200 Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote:
>
> > Leif Halvard Silli wrote:
> >> But why _haven't_ WHATwg proposed to remove it? FOR/ID and HEADERS/ID are
> >> twins - they're there for the same reasons!
> >
> > Although they are both forms of explicit association, they're not included
> > for the same reason.  These are some 
> additional reasons for including for=""
> > that do not apply to headers="".
>
>Explicit - or «hard coded» associations are used 
>to overrule/add to the implicit associations 
>created by containership. I fail to see that you are describing other reasons:
>
> > * Allows for labels and controls to be separated, which allows for more
> > flexibility in the structure and style of the page.
>
>It allows for flexible/sloppy** coding praxis 
>for FORMs (= the "page"). Just as 
>HEADERS/ID  allows free association of TABLE 
>cells with cells outside their natural row/column container.
>
>**Sloppy: to nest controls in LABEL elements should be recommended practise.
>
> > * Increased usability by allowing users to click on the label to focus the
> > control. That's particularly important for checkboxes and radio buttons.
>
>It is the association which creates this 
>functionality/usability.  It doesn't matter 
>whether you use FOR/ID or if you rely on containership.
>
> > * It is very widely used in reality.
>
>Reality? We are talking media here. Hypermedia. 
>:-D Else, by «same reasons», I was referring to HTML4.
>
> >> It is logically inconsistent to keep the one combination that happens to
> >> assists sighted persons (FOR/ID), while at 
> the same time propose to remove
> >> the one that (due to lack of follow-up of what HTML4 actually proposes)
> >> _only_ assists visually impaired (HEADERS/ID).
> >
> > I disagree about it being logically inconsistent because of that rather
> > significant difference,
>
>I fail to see that you established any different 
>reasons at all. The one thing that differes is 
>of course how often they occurs in documents. 
>But that is nothing new. It remains that for the 
>most part, both FOR/ID and HEADERS/ID are used 
>for compatibility reasons - and not for usability reasons.
>
> > but regardless of that, it seems likely that the
> > headers attribute will be added in due course.
>
>This is good to notice. But then again, HEADERS 
>is not an island. Are we dropping the new SCOPE 
>algorithm in favour of the old algoritms of 
>HTML4?  Why shall AT browsers adapt to new 
>algoritms? Will we essentially be able to say 
>the same about TABLE that is currently said 
>about FORM? Namely that «This section will be a 
>rewrite of the HTML4 [...] with hopefully no normative changes»? [1]
>
> >> Lesson: To make HTML «accessible by design», it would be a good strategy
> >> strive to ensure that accessibilty 
> elements/attributes also assists sighted
> >> persons.
> >
> > Yes, whenever possible, that's a reasonable strategy to follow.
>
>And then you have of course thought about why it 
>is - or isn't - a reasonable strategy to follow 
>when it comes to showing associations in TABLEs?
>
>Can we _add_ usability for sighted people as well?
>
>[http://www.whatwg.org/specs/web-apps/current-work/#forms]
>--
>leif halvard silli

Received on Monday, 6 August 2007 00:34:59 UTC