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

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?

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.

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...

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...

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, why would anyone object to making summary 
a required attribute of TABLE?

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.
-------------------------------------------------------------------
CYNIC, n. A blackguard whose faulty vision sees things as they are, 
not as they ought to be. Hence the custom among the Scythians of 
plucking out a cynic's eyes to improve his vision.
                          -- Ambrose Bierce, The Devil's Dictionary
-------------------------------------------------------------------
          Gregory J. Rosmaita, oedipus@hicom.net
UBATS - United Blind Advocates for Talking Signs: http://ubats.org/
-------------------------------------------------------------------

---------- Original Message -----------
From: Bill Mason <w3c@accessibleinter.net>
To: public-html@w3.org
Sent: Sun, 24 Jun 2007 17:31:41 -0700
Subject: Re: danger of null value for summary attribute [Re: fear 
of "invisible  metadata"]

> Gregory J. Rosmaita wrote:
> > a null value for summary defeats the entire purpose of alerting the 
> > user who cannot process the table at all or in toto, how the table 
> > is laid out, what it describes, etc.
> > 
> > rather than a null value for summary, layout tables should CLEARLY 
> > be marked summary="Layout Table Containing X", so that the user 
> > knows he or she can skip that table and move on to inspect the 
> > next table, courtesy of the summary attribute... after all, aren't 
> > MOST tables found in the wild are quote layout tables unquote?  
> > even though they are misusing the table element, they are using 
> > a table to (literally) lay out content in a particular manner, 
> > alignment, ect.
> > 
> > speaking as a screen reader
> 
> Considering that your assertion that all tables (including 
> layout tables) should have a non-null summary attribute value 
> flies in the face of:
> 
> * Current WCAG WG thinking [1]
> * Advice from at least one major web accessibility group [2]
> * Advice from one of the better known web accessibility guides 
> [3], currently in the top ten of Google results for "layout 
> table summary"
> 
> ...it would be useful to justify this stance before using it as 
> an argument for keeping the summary attribute in HTML5.
> 
> -- 
> Bill Mason
> Accessible Internet
> w3c@accessibleinter.net
> http://accessibleinter.net/
> 
> [1] http://www.w3.org/TR/2007/WD-WCAG20-TECHS-20070517/Overview.html#H73
> [2] http://www.webaim.org/techniques/tables/data.php#summaries
> [3] 
> 
http://diveintoaccessibility.org/day_20_providing_a_summary_for_tables.htm
l
------- End of Original Message -------

Received on Monday, 25 June 2007 05:48:12 UTC