Re: Call for Consensus - Last Call responses on longdesc extension

I object to these resolutions.

> Matt objected:
> [[[
> As far as I know, no implementer has added support for making longdesc
> perceivable/"discoverable" to all users and the relevant bug has been
> wontfixed in Firefox:
> https://bugzilla.mozilla.org/show_bug.cgi?id=884927
>
> This is probably because the current web corpus of longdesc usage is so
> hopelessly polluted, the only effect of making longdesc perceivable to all
> would be to make sighted users give up on longdesc, like most SR users
> already have:
> http://lists.w3.org/Archives/Public/public-html/2007Sep/0350.html
>
> It seems likely longdesc will continue to give the pretense of serving
> accessibility while not actually providing it:
> www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/results
>
> The spec should be updated to reflect reality.
> ]]]
>
> Resolution:
> The proposed response is accepted. The TF coordinators found that Matt's
> statement is incorrect, although browser-native implementations are
> generally not very high quality, and the rest of his comment is irrelevant
> to the question.

Can you list which browsers currently make longdesc
perceivable/"discoverable" to all users? Mozilla has wontfixed the
bug. Which bit of this statement is "incorrect" exactly?

(FWIW I don't think this will be a massive issue as long as the
longdesc test results accurately reflect the "quality" of the
"browser-native implementations")

> Matt objected:
> [[[
> The discoverability requirements identified by the use cases are all met by
> using a normal link. The purpose of use cases is to identify user
> requirements. None of the use cases require the description link to be
> discernible as different from a normal link, and no evidence has been
> presented showing users are aware of this artificial distinction or would
> benefit in any way from being made aware of it.
>
> This markup already meets all the use cases requirements, and provides
> better discoverability without introducing the well-known problems
> associated with longdesc usage:
>
> <a href=desc><img src=pic alt="*the purpose of the link*></a>
>
> People should be able to tell from the spec what longdesc is for and,
> specifically, when it should be used. The spec needs to define the
> conditions for when (if ever) authors should use longdesc instead of a
> normal link i.e. the conditions where a normal link is sufficient, and the
> conditions where a normal link is insufficient and a longdesc link should be
> used instead.
> ]]]
>
> Resolution:
> The proposed response is accepted. The TF Coordinators found Matt's
> statement that the use cases do not require discoverability is incorrect. In
> addition, user agents require discoverability to propose the description to
> users in a consistent way

My comment stated a normal link provides "better discoverability".
This has been re-written as saying "the use cases do not require
discoverability". This is silly. Either the W3C process has value and
should be followed, or it has no value and there's no point pretending
to follow it.

People reading the spec should be able to tell when to use a longdesc
link instead of a normal link, i.e. what problem longdesc solves.
Since normal links currently meet all the requirements identified in
the use cases and provide *better* discoverability, the spec needs to
specify when longdesc should be used instead of a normal link to avoid
creating another WAI accessibility disaster.

For example, we've known for over a decade that everyone appreciates
long descriptions of artworks:
http://www.csun.edu/cod/conf/2001/proceedings/0031alonzo.htm

Should authors remove their existing normal links to long descriptions
of artworks and replace them with longdesc links? The spec doesn't
make this clear at all.

> and his proposed alternative is impossible where
> an image is already part of a link.

This scenario can already be addressed with normal links, as we've
previously discussed:

http://lists.w3.org/Archives/Public/public-html-a11y/2012Apr/0040.html
http://lists.w3.org/Archives/Public/public-html-a11y/2012Apr/0041.html

[crop]

> Matt objected:
> [[[
> Image search is already widely implemented using more advanced techniques
> also used for document search like alt, context, page topic, links etc e.g.
> http://images.google.com/
>
> Current usage of longdesc is also hopelessly polluted, and we haven't
> identified when if ever, a longdesc link should be used instead of a normal
> link anyway, as above.
> ]]]
>
> Resolution:
> The proposed response is accepted. The TF Coordinators consider it unclear
> whether Matt actually has any experience implementing or represents any
> search engine, while the commenter clearly does.

This is a fatuous attempt at an argument from authority:
http://en.wikipedia.org/wiki/Argument_from_authority

In this case Charles' employment at Yandex appears to be based
entirely on his association with the W3C, rather than any specific
domain expertise or experience, but this obviously does not mean the
points he makes are automatically wrong any more than it means they
are automatically right. Whether Charles currently works for a search
engine company or anyone else, the validity of the points he makes
depends on the arguments and evidence he puts forward, not who he
works for, and the same point of course equally applies to everyone
else. This shouldn't need to be pointed out.

If a search engine was to start using longdesc for image search
results, the overwhelmingly poor quality of existing longdesc usage
would obviously have a significant negative impact on the quality of
image search results presented to users, and this point really should
be immediately and intuitively obvious to everyone, whether they work
for a search engine company or not.

Regardless, we still don't know when longdesc is actually supposed to be used.

What The Spec Needs To Do
-------------------------

The spec needs to define when longdesc should be used i.e. what
problem longdesc solves. People reading the spec should be able to
tell when to use a longdesc link, instead of a normal link. The spec
does not currently explain what longdesc is actually for, or when to
use it. Some possible answers include:

1. a longdesc link should always be used instead of a normal link when
the destination includes a description of the image

2. a longdesc link should be used instead of a normal link when [some
other criteria that needs to be defined in the spec]

3. a longdesc link and a normal link should be used together when
[some other criteria that needs to be defined in the spec]

4. a longdesc link should be used instead of a normal link when the
description is only needed by some AT-users [define criteria authors
can use to decide a description is only needed by some AT-users]

etc

Defining this will also help authors decide when to use
aria-describedat, so it's worth doing anyway.

-Matt

Received on Thursday, 19 December 2013 17:50:47 UTC