- From: Debi Orton <oradnio@gmail.com>
- Date: Sun, 05 Aug 2007 20:32:46 -0400
- To: public-html@w3.org
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