- From: Charles McCathieNevile <chaals@opera.com>
- Date: Wed, 06 Feb 2008 12:05:00 +0530
- To: "HTML WG" <public-html@w3.org>
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