- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Sun, 24 Jun 2007 14:59:58 -0400
- To: James Graham <jg307@cam.ac.uk>
- Cc: HTML WG <public-html@w3.org>
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