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

aloha, james!

can you list for me the total number of screen-readers that support aural 
stylesheets?  i can count them on one hand -- with fingers to spare...

besides, CSS2.1 has deprecated aural CSS to a normative appendix, and 
have changed the media selector type to speech from aural, which is 
a gigantic step backwards, as there are valid user scenarios where a 
user with a learning disability benefits from magnified text in a limited 
viewport with purely earconic feedback...   aural CSS ain't just for 
screen-readers, it exists to provide a rich aural canvas that can either 
enhance a user's understanding of the content and its relationship to 
other content, either as a substitute for screen-scraping kludges, or 
as important, but not obtrusive, cues that help orient blind, low 
sighted, and those with certain learning disabilities...

as for CSS3 there are currently 3 aural CSS modules in development, so 
i wouldn't count on the magic of aural styling to immediately (or in 
the near future) to provide any solution for every blind, low vision, 
or learning disabled user...

gregory.

----------------------------------------------------------------
CONSERVATIVE, n.  A statesman who is enamored of existing evils,
as distinguished from the Liberal, who wishes to replace them 
with others.         -- Ambrose Bierce, _The Devil's Dictionary_
----------------------------------------------------------------
             Gregory J. Rosmaita, oedipus@hicom.net
  Camera Obscura: http://www.hicom.net/~oedipus/index.html
----------------------------------------------------------------


---------- Original Message -----------
From: James Graham <jg307@cam.ac.uk>
To: "Gregory J. Rosmaita" <oedipus@hicom.net>
Cc: HTML WG <public-html@w3.org>
Sent: Mon, 18 Jun 2007 22:22:33 +0100
Subject: Re: fear of "invisible metadata" [was Re: retention of summary 
attribute  for TABLE element]

> 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
------- End of Original Message -------

Received on Sunday, 24 June 2007 19:00:08 UTC