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

Sorry for the delay in response. It's my fault for being busy with other  
stuff.

There were not a lot of responses, but most of the proposed resolutions to  
comments were accepted. There were three negative responses to the  
proposed resolutions for the longdesc spec last call comments, all from  
Matt Turvey.

I'll list the individual responses and how we have resolved to deal with  
them. Please note that there will also be a CfC to cover two of the cases  
which resulted in objections to the original proposals.

===
Commenter: Guy Moreau
Comment summary: Suggestion to add text that requires UAs to make  
longdescs actionable (like regular links)
Proposed response: This is an unnecessary restriction.
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.

===
Commenter: Jan Richards
Comment summary: Update the informative links regarding accessibility  
testing to ATAG, so they point to more specific information.
Proposed response: Agreed. Editorial change proposed to the specification.

Resolution:
The proposed response is accepted.

===
Commenter: James Craig / Matt Turvey
Comment summary: Add notes saying when longdesc is inappropriate.
Proposed response: Partially agreed. Editorial change proposed to the  
specification highlighting circumstances where longdesc is not a  
sufficient solution.

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, and his proposed alternative is  
impossible where an image is already part of a link.

===
Commenter: Andrew Kirkpatrick
Comment summary: Should UAs be *required* to read only the fragment  
referenced where a longdesc is not a complete page?
Proposed response: No, the existing requirement is sufficient and reflects  
realistic possibility, since HTML has no formal way to determine what a  
fragment identifier refers to. No change proposed to the specification.

Resolution:
The proposed response is accepted.

===
Commenter: EOWG
Comment summary: Various editorial suggestions
Proposed response: Partially agreed. Editorial changes proposed to the  
specification.

Resolution:
The proposed response is accepted.

===
Commenter: Charles McCathie Nevile
Comment summary: For search engines, a use case is identifying  
descriptions in order to use their content to improve text search for  
images
Proposed response: Agreed. Editorial change proposed to the specification.

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.

For the Task Force Coordinators

Chaals

On Tue, 22 Oct 2013 03:17:56 +0200, Charles McCathie Nevile  
<chaals@yandex-team.ru> wrote:

> Hi folks,
>
> this is a call for consensus on each of the proposed responses to  
> comments received on the Last Call draft of HTML Image Description  
> Extension.
>
> There is a Web-based survey, to simplify replying to each comment  
> individually. Please fill it out at  
> https://www.w3.org/2002/09/wbs/44061/ProposedLongdescCommentResponses/  
> and note that the deadline for response is one minute before midnight  
> Boston time on Monday, 28 October.
>
> Silence will be considered assent, but positive response is strongly  
> preferred. To further simplify, there is an option to accept (or to  
> concur for) all proposals. But please note that some proposed responses  
> include making changes to the specification, so we strongly request that  
> you read them…
>
> For the facilitators
>
> Chaals
>


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

Received on Thursday, 5 December 2013 08:08:24 UTC