- From: James Graham <jg307@cam.ac.uk>
- Date: Wed, 06 Feb 2008 10:09:39 +0000
- To: Charles McCathieNevile <chaals@opera.com>
- CC: HTML WG <public-html@w3.org>
Charles McCathieNevile wrote: > Could someone with access to the issue tracker please raise an issue > for whether longdesc should be deprecated? Done. Since your name was one of the options for "Raised by" I selected that. I hope this is the right thing to do and not seen as me putting words in your mouth (perhaps someone could clarify that for me? I was working on the assumption that "Raised By" would be fixed to the login name if that was always the right thing to do.) > Actually, I disagree on this. In our own research into about a million > pages we came up with a low usage of longdesc - a bit less than one > per cent of pages. And of that usage, something like half to > two-thirds was totally useless. (It would be interesting to have a little more information of the methodology used in your research, e.g. how you chose the sites) > But I draw a different conclusion on what that actually means to > users. Most users don't care about longdesc, they look at the picture, > and don't even know if it has a long description, so the longdesc > attribute value has exactly zero relevance to them. Of the few users > who rely on it, or benefit substantially from it (who are currently > primarily screen reader users - along with iCab users they are the > only people with ready access to tthe functionality anyway) most are > in a position where something that works 20% of the time is better > than something that doesn't work at all, since they do not get an > alternative. I think this 20% number is misleading in describing how often longdesc "works"; unless I have understood incorrectly, 20% represents, in terms of a conditional probability P(longdesc is useful | longdesc exists) whereas the interesting number is something closer to P(longdesc is useful | longdesc is needed) actually even this might not be quite right, because one can always argue about the definition of the word "needed" here. Taking the position that a longdesc is only "needed" if there is no reasonable way to convey the information in HTML 4 without using longdesc (i.e. the information is so important that it is required to understand the page but cannot reasonably be displayed to a sighted user or either inline of via a link), there might be difficulty calculating this probability due to lack of cases. Taking the opposite extreme and assuming longdesc is needed every time there is an image that benefits from further explanation then this secong probability is clearly much much less than the first. > There are a number of cases where it would be easy to provide > longdesc. One example is sites that provide walking or driving > directions both as a map and as a textual explanation of the route > (yes, I do ask blind friends to get me driving directions to somewhere > and blind people do give driving directions to their house, favourite > pub, etc). While I suspect most site authors will not do this in the > coming 5 years, helpful usage of the attribute has certainly increased > dramatically over the last 10 despite there being no way to access its > content for half that time. I don't understand why longdesc is useful here. If the site provides both text and a map (which it should because the text is beneficial to everyone) there is no obvious requirement for an invisible indicator that the text is an alternative to the map; the screenreader can jut ignore the map and read the text. >>> Surely even new and hitherto undreamed of attributes and elements are >>> potentially as susceptible to misuse - but is this a solid reason for >>> not developing them? >> >> We must design a language that is more likely to be used correctly than >> wrongly, yes. > > I don't think this is an accurate statement of the requirement. We > should design a language that leads to its correct use. We ust design > a language that supports the needs of its users. (In the Design > Principles, the one about relative importance of audiences is relevant > here - if it is harder for users to understand what is happening > without longdescs than it is for authors to get them right, then > longdesc makes more sense. Other relevant points include backward > compatibility, universal access, and paving cowpaths - in this case a > body of work and tools explaining to authors and tool developers how > to add descriptions to existing content). As a slight aside the Priority of Constituencies design principle should probably mention that it's generally not possible to separate things cleanly between users/authors/implementors. For example there's no point in introducing a change that implementors won't implement, even though it would help end users. However, in this case it's not at all clear to me that @longdesc does benefit users because it's not clear that encouraging the alternative as best practice (solutions involving visible content accessible to all users) wouldn't help the people who supposedly need @longdesc more often. To extend the cowpath metaphor a little, it's like one of those times when you see a track that looks like a path but as you wander down it it rapidly gets fainter until it disappears into a tangle to brambles. At this point the right thing to do is probably to turn back and look for a different, more passable, route to our destination.
Received on Wednesday, 6 February 2008 10:09:50 UTC