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

Re: fear of "invisible metadata" [was Re: retention of summary attribute for TABLE element]

From: James Graham <jg307@cam.ac.uk>
Date: Mon, 18 Jun 2007 22:22:33 +0100
Message-ID: <4676F799.4080101@cam.ac.uk>
To: "Gregory J. Rosmaita" <oedipus@hicom.net>
Cc: HTML WG <public-html@w3.org>

Gregory J. Rosmaita wrote:
>> Summary is explicitly invisible metadata and therefore is more 
>> likely to be missing or inaccurate than data that is visible to 
>> all UAs. 
> 
> 1. poor authoring practices should NOT sway or inform our decisions

That makes for nice rhetoric but I'm not sure it is actually the policy 
that will result in the most accessible HTML documents overall. We can 
try to ignore the huge number of "poor" authors and moan that that 
they're uneducated and don't follow best practices. We can even try to 
remedy the situation by attempting to educate people on those best 
practices. However, human nature dictates that people will always get 
away with doing just enough to achieve their intended result. Often this 
will be through sheer ignorance; most people, and often those with the 
most interesting content, are not markup geeks. They haven't studied 
specs, read the whole tutorial or attended expensive workshops and 
conferences. They know just enough to get their desired rendering which, 
typically, is in a visual web browser. This is absolutely not a 
criticism of such people; I do things all the time in fields where a 
domain expert would describe me as ignorant. Other times people don't 
conform to all the best-practices because their boss wants the site 
finished /yesterday/ and they have another few thousand lines of Ruby to 
write to make the ordering system talk to the database in accounts - 
and, well, the HTML seems to be working so why fuss with it?

The point it that it's foolhardy to design the language around the 
assumption that all authors will be domain-experts in HTML. "Poor" 
authoring practice should absolutely inform our decisions because, if we 
can make the language work well when used naively then the overall 
accessibility of content will be improved for everyone (one can, for 
example, use this argument to justify writing an algorithm for parsing 
HTML "as she are spoke" rather than insisting on well formed XML 
everywhere).

> 2. invisible to whom?

Users of visual UAs, the vast majority of the browsing population. The 
fact is that most sites are designed primarily with visual UAs in mind 
because that's what the majority of people use. With this in mind it is 
considerably better to /reuse/ information available to people using 
visual UAs where possible, rather than hope that authors will be 
conscientious enough to provide (and keep up to date) additional data 
that they (probably) cannot access in their own UA.

This should mot be taken as a suggestion that users of visual UAs are 
more /important/ than users of non-visual UAs. They are not.

>> I hypothesize that in many cases pages already include text that 
>> summarises the contents of a table to the extent needed to identify 
>> whether the table is of interest; in order to allow non-visual 
>> browsers to easily scan a page, I would provide a mechanism to 
>> associate this text with the table. Authors wishing to provide extra 
>> information hidden from visual UAs (e.g. because it describes the 
>> table in a level of detail not required by sighted users) could use 
>> CSS to explicitly hide that information. 
> 
> NO, NO, NO -- summary information should not be hidden by CSS -- this 
> isn't about style, it's about substance

The point is that CSS provides a mechanism to selectively make 
information available based on media type which can be used in 
situations where there is a genuine need for extra detail in specific 
renderings.

> summary should be deprecated because it is invisible 
> to visual users?  what kind of logic is that?  the whole damn document is 
> invisible to blind users, or only partially visible to low vision users, 
> so i think your fear of quote invisible unquote metadata is unfounded and 
> unrealistic...  visually, it is possible to obtain an overview of a 
> document, and moving one's eyeballs has no effect on navigation -- blind 
> users don't have that luxury, which is why quote invisible metadata 
> unquote, such as summary are necessary...

"Invisible" in the sense of "not trivially accessible in their UA" e.g. 
a user of a graphical web browser has no easy way to see the contents of 
the summary attribute in their UA.

> visual users DON'T need a summary, due to the constant reinforcement of 
> the TABLE's structure, function and contents which is a side effect of 
> vision and the ability to associate data via spatial relationships...

Which also makes it unlikely that most authors will write a summary 
attribute. Therefore I propose that we analyze the *use cases* that 
summary is supposed to fill and see if there is a way of fulfilling 
those use cases whilst minimizing the burden on authors. It may turn out 
that the summary attribute is that optimum solution. However I don't 
think that is obvious.

> you wouldn't deprecate ALT or LONGDESC would you

Actually, longdesc is not included in the current draft of HTML5. Are 
there a non-negligible number of sites that actually use longdesc in a 
useful way?

-- 
"Instructions to follow very carefully.
Go to Tesco's.  Go to the coffee aisle.  Look at the instant coffee. 
Notice that Kenco now comes in refil packs.  Admire the tray on the 
shelf.  It's exquiste corrugated boxiness. The way how it didn't get 
crushed on its long journey from the factory. Now pick up a refil bag. 
Admire the antioxidant claim.  Gaze in awe at the environmental claims 
written on the back of the refil bag.  Start stroking it gently, its my 
packaging precious, all mine....  Be thankful that Amy has only given 
you the highlights of the reasons why that bag is so brilliant."
-- ajs
Received on Monday, 18 June 2007 21:22:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:45 UTC