Re: Formal Recorded Complaint

On 2007-07-31 22:29:35 +0100 James Graham <jg307@cam.ac.uk> wrote:

> Robert Burns wrote:

>> Often times (like in the case of @headers) the attempt to purge 
>> accessibility features from HTML has even extended to features of HTML that 
>> are not even particularly about accessibility but instead about explicitly 
>> expressing semantics within complex documents (just because it may have 
>> some accessibility implications)
> 
> I would argue that semantics-for-the-sake-of-semantics is not Solving Real 
> Problems (c.f. the design principles).

This argument here doesn't solve «real problems». We are all in favour of accessibility. And we we are also all against semantics for the sake of semantics.

[...]
> Pretending, for a moment, that we agree that semantic markup for its own sake 
> is a bad idea, what about @headers? [...]

> It is very much an explicit way of marking up the data; 

In the same way that FOR= is.

> @headers is not 
> useful for most users so authors are likely to neglect to include it.
>
> Even for authors who want it, it's hard to author (it requires the headers to 
> be specified on _every_ cell; increasing the possibility of authoring 
> mistake).

And this is were you go wrong: HEADERS= has a wider use than FOR= has. You can make good use of HEADERS= without using it the way FOR= is (mis)used (that is: on every LABEL) . I.e. you do _not_ have to put in in every datacell. And as Ferg says about HEADERS= (used the inteligent way) that «This seems to be the simplest and most straightforward technique of all.» <http://www.ferg.org/section508/accessible_tables.html#contents_item_6.3>.

> It may encourage authors to use over-complex tables. By making the tables 
> over complex, authors may prevent visually disabled users from forming an 
> accurate view of the relationships expressed in the table even with the 
> cell-headers association. This may also prevent some other users (without 
> visual impairment) from correctly understanding the table.

Frankly, I think this argument is taken out of the air. It is *theoretical* possibility that it might happen. But not very likely. The risk with HEADERS= and FOR= is the same: people may resort to using them in _every_ label/cell, instead of learning how to use them when really needed.

However, the use of FOR= in LABELs has lead to the unneccessary «free» layouts of simple contact FORMs. Or why use <LABEL>Label</LABEL><INPUT> when <LABEL>Label <INPUT></LABEL>, which undoes the need for FOR=, is possible (except, of course for compatibility reasons)?

Btw - regarding FOR=: The relationship between DT and DD is created by the order they appear in the source. (And Aurelien's suggestion to have a FOR= attribute for DT, so one could place the DD before the DT was dismissed not so long ago.) One could most certainly require that when a LABEL/INPUT relationship is not connected via containership, then instead of FOR= the order of appearance should apply: The INPUT should be connected with the nearest preceding LABEL.
-- 
leif halvard silli

Received on Monday, 6 August 2007 15:27:39 UTC