W3C home > Mailing lists > Public > public-html@w3.org > June 2007

Re: danger of null value for summary attribute [Re: fear of "invisible metadata"]

From: Bill Mason <w3c@accessibleinter.net>
Date: Mon, 25 Jun 2007 01:24:13 -0700
Message-ID: <467F7BAD.6090405@accessibleinter.net>
To: public-html@w3.org

Gregory J. Rosmaita wrote:
> aloha, bill!
> 
> isn't the point of the exercise to improve the quality of the product?
> surely that is what the HTML WG is chartered to do, develop
> 
> quote (source: http://www.w3.org/2007/03/HTML-WG-charter)
>  * A language evolved from HTML4 for describing the semantics of 
>    documents and applications on the World Wide Web. This will be 
>    a complete specification, not a delta specification.
> unquote
> 
> what then, constructive, do you have to add to the discussion?

If you find my messages non-constructive, feel free to ignore them.

> i've already quote justified unquote my proposal and the reasons 
> behind it, but here we go again:
> 
> if i peruse an online circular, and it is comprised completely of 
> tables, do i not need to know that the first table contains 
> a recurring menu of choices; the second, a means of searching 
> the site; the table where the specials are visually laid out (often 
> without ALT or explicit orientational text) and i ESPECIALLY 
> need summaries on the tables that contain the forms through 
> which i transact with a business (although i'd prefer fieldsets, 
> legends, and labels - or just plain wholesale adoption of XForms);
> which table contains the confirmation information before i 
> finalize the order slash transaction, etc.

The odds that authors of such pages are going to update the code to HTML 
5 and put in such summaries are minimal, any more than those authors 
dropped their layout tables for CSS when it became available.  HTML 5 is 
not going to fix your problems with legacy pages using tables for layout.

> go to your online banking interface -- chances are, everything 
> is stuck in tables that nest like rabbits, so i fail to understand 
> why it would be a bad thing if summary was a required attribute
> of TABLE, whether or not that TABLE is used to display data set 
> relationships, or being mis-used in an attempt to control the 
> layout of the page...

My online bank home page has exactly one table, to lay out 3 images 
horizontally -- and that probably could have been done via CSS float or 
positioning.

Requiring summary is undesirable because:

* Layout tables are slated to be nonconforming anyway, and mandating 
summary on all data tables is not necessarily desirable (see below)

* I would doubt there will be a great number of authors of a knowledge 
level to both know of and want to create conforming HTML 5 code and 
still construct a page of not just a layout table, but multiple nested 
layout tables.

> if you are using TABLE as a grouping mechanism, then why not 
> require that a summary of its use and intention be made available 
> to those who cannot perceive the grouping?  that is why the 
> value summary="" (summary equals-sign quote quote - the 
> equivalent of a null alt value) should cause a validator to return 
> an error when the page is analyzed...

Even if we pretend that all HTML 5 pages will never have a layout table, 
it is entirely possible (as was recently suggested) [1] to provide 
summary information outside the summary attribute, thus making having 
one a requirement a problem.

> layout tables aren't simply quote graphical unquote or quote 
> stylistic unquote -- they have been constructed precisely for 
> the purpose of grouping information into discrete visual portals 
> in order to maximize screen real estate (er, the visual canvas) 
> and to communicate visually that this thing belongs to this set 
> of things, while these things belong to another set of things 
> entirely...

Given that the intent of the specification is to make layout tables 
nonconforming, if people use them anyway I doubt their conformance to 
the use of summary will be the uppermost thing on their mind.

> given that, why would anyone object to making summary 
> a required attribute of TABLE?

See above.

Suffice to say, regarding the rest, I don't think you've made a valid 
justification for requiring summary.  As I noted elsewhere [2], I 
believe summary belongs in the specification, but I don't find your 
rationale to be an argument for that belief.

> besides, bill -- accessibility is in the eye, ear, fingertip, or 
> some combination thereof of the beholder...  you asked for a 
> justification, when there has been a need identified, and a 
> proposal has been made, and a pre-existing solution happens to 
> provide a means of satisfying that need TODAY, not when HTMLx is 
> finally offered to the public...  besides, verbosity is best left 
> to the end-user to decide, not for a webmaster to make an assumption 
> (such as this is purely decorative, or this doesn't qualify as content 
> -- it's art); that being said, i'd rather hear the contents of a null 
> ALT text than innumerable string such as: quote spacer unquote; 
> quote clear pixel unquote; quote indecipherable filename unquote; 
> and so on, but if you are using a TABLE as a layout table, you 
> are doing so to convey something to the user, even if you don't 
> realize it -- that here, and here, and here and here you can 
> find related information...  who knows -- perhaps the onerus 
> burden of providing a summary will be a disincentive for 
> page authors to misue table to achieve layout effects...
> 
> i have had countless persons, who, after asking me to spec a machine 
> for a blind employee that would allow the employee access to the 
> office's new network, express surprise when i recommend (if the user 
> is braille literate) that they provide both a screen reader and a 
> refreshable braille display...  can't they do with one or the other, 
> they ask, to which i reply, you wouldn't force a sighted employee to 
> choose exclusively between the use of a screen or the use of a 
> printer, would you?
> 
> the bottom line is: make the information available and allow the end
> user to set the verbosity slash level of granularization they want -- 
> and remember, in different circumstances, one's need for and/or 
> tolerance of orientational and contextual information varies greatly,
> from document to document, user to user...
> 
> gregory.

-- 
Bill Mason
Accessible Internet
w3c@accessibleinter.net
http://accessibleinter.net/

[1] http://www.wcagsamurai.org/errata/intro.html
[2] http://lists.w3.org/Archives/Public/public-html/2007Jun/0684.html
Received on Monday, 25 June 2007 08:24:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:01 GMT