longdesc Re: Clarification of rational for deprecation...

Leaving aside @summary to focus on things one by one. Please note that the  
following is not a formal Opera position, as we don't yet have one on this  
issue, but is my opinion after discussing this with various people inside  
Opera (and working on this stuff for a decade or so). If and when the  
issue comes for formal resolution in the working group we will develop a  
formal position.

Could someone with access to the issue tracker please raise an issue for  
whether longdesc should be deprecated?

On Wed, 06 Feb 2008 01:10:40 +0530, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 5 Feb 2008, Joshue O Connor wrote:
>>
>> I am wondering if you could expand a little on your response.
>> Hixie had opined:
>> > I also think longdesc="" and summary="" have thought us that placing
>> > attributes for specific disabilities into the language itself will
>> > result in overwhelming abuse to the point where the target audience of
>> > those features actually have to turn them off.

I don't think that people need to turn longdesc off. They may be  
disappointed in the results many times, but that's different. I am often  
disappointed in useless results I get from Google, yet I still find it one  
of the most useful things on the web for the times when it gives me useful  
information. (Admittedly, Google works more often than longdesc. On the  
other hand, there are more alternatives to Google).

So while some things (especially while they were not well supported) have  
resulted in abuse, I don't think it follows that we should therefore  
assume there is no baby in the bath, and just tip it all out - especially,  
if the actual cost of the abuse is low, and in the longdesc case I claim  
that the real cost of abuse compared to the benefit of good use is  
vanishingly small even when most usage is incorrect.

>> I guess you are referring to using @summary for black hat SEO, but even
>> so, is this a solid enough reason to drop it from the HTML 5 spec?
>
> The summary="" attribute hasn't been studied as carefully as longdesc="",
> so it's probably easiest to look at the longdesc="" data (though
> eventually we will of course have to look at summary="" specifically as
> well). For longdesc="", it's pretty clear that the attribute is used so
> rarely, and when used, is so overwhelmingly often used in a way that  
> would annoy users, that I simply cannot see a scenario on the open Web
> where a user would actually benefit from a user agent impementing the 
> longdesc="" attribute.

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.

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.

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.

Longdesc is hidden metadata, which can be seen as a disadvantage. But  
then, that provides the advantage that people often don't want to know  
that it is there - if authors had to have it appear in all presentations  
experience suggests they would be far more likely to blank it out for  
aesthetic reasons than to use it helpfully for relevant cases. In these  
days of image libraries, with searchable tagged content, and reasonably  
powerful image manipulation software, I expect longdesc to become ever  
easier to use intelligently in semi-automated systems from photo  
publishing to generation of presentations and reports.

It is also potentially open to blackhat SEO use if it becomes popular. But  
I don't see an alternative to it that isn't - and there are techniques  
particularly appropriate to content aggregators such as search engines of  
detecting such use and sidestepping it.

...
>> 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).

In conclusion, I think the rationale for deprecating the attribute fails  
to take appropraite account of how its accessibility use case plays out in  
the real world, and of what it offers people. It may be appropriate to  
develop a new and hopefully better alternative to longdesc alongside the  
current HTML 4 version, but I have not seen any proposal that actually  
meets the same needs. I therefore think we should not deprecate the  
attribute.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Received on Wednesday, 6 February 2008 06:35:23 UTC