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