- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Thu, 05 Dec 2013 09:07:47 +0100
- To: "public-html-a11y@w3.org" <public-html-a11y@w3.org>, "Charles McCathie Nevile" <chaals@yandex-team.ru>
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