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

On Thu, 19 Dec 2013 21:50:18 +0400, Matthew Turvey <mcturvey@gmail.com>
wrote:

> 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?

iCab has "always" made longdesc discoverable to all users.

Opera 10-12 browsers did so through a context menu - the same poor
quality as Firefox, but nevertheless usable in a pinch.

> (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")

They will continue to do so.

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

Which ignores the specification, where the requirement called
"Discoverability" which makes it explicit that a user agent must be able
to determine that there is a description. ("better discoverability"
depends on your perspective, which is why the spec explicitly states what
it means).

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

Your statement is a rejection of the requirement named "discoverability",
specifically the aspect of unambiguous identification of descriptions. The
initial response may have been clearer if it had more explicitly stated
so, but the logic remains the same.

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

The specification makes no suggestion that they should, it merely suggests
that images which have a long description available should include a
longdesc attribute linking to that description.

While such usage may seem redundant, it helps by for example automatically
disambiguating between the case where an image links to a description of
the image, and the case where an image links to a discussion of some other
aspect, such as the history of the image or its use in some event.

The changes proposed will further clarify that there are cases where a
longdesc may be redundant, providing benefit for certain users without
being the only way to provide easy access to descriptions.

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

Which cannot be done to images which are already used as links without
changing the meaning of the content. Which is why this repeated suggestion
is still not accepted as showing that there is an alternative solution
available.

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

Indeed.

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

As is normal in W3C, a member company has discussed the issue internally,
and provided their feedback.

Your initial argument is based on the unsubstantiated assumption that
Google does not use and would not benefit from the presence of longdesc
attributes. Were this argument to be substantiated, it is a single data
point, in which the question turns to the balance of benefits and the
strength of objections.

Your argument above is based on the faulty premise that search engines do
not sanitise the data they use. In reality "General Web" search engines
are known to do all kinds of sanitisation, rather than simply accepting
all content at face value. Likewise there are specific-purpose search
engines which are used on controlled data sets, and would thus benefit
 from good uses while being effectively protected from poor usage.

Yandex' position is that we strongly prefer to allow the continued use of
the attribute as we feel that even when misused it does insignificant harm
in practice, that in the cases where it is used correctly it will be of
real concrete benefit, and that keeping it will lead to slowly increasing
proportion of good use (much as has been the case with alt over the last
two decades).

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

When there is a description available for an image included through an
image element.

The Working Group's proposal to modify the text, clarifying that in some
cases there are alternative approaches available, stands. Please state
whether you accept the resolution, or would like to record a formal
objection.

In the event that you do not reply, your ongoing opposition to this
specification will in any case be noted and brought to the attention of
the W3C Director when evaluating a request to Transition to a later stage.

For the TF Coordinators

Chaals

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


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
             chaals@yandex-team.ru         Find more at http://yandex.com

Received on Monday, 17 February 2014 11:05:30 UTC