Re: ISSUE-30 longdesc Re: Clarification of rational for deprecation...

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