- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Thu, 13 Dec 2012 22:54:27 +0000
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
- Message-ID: <CA+ri+VmTbY_rkC+2aBU9GPqsO0PMBLF0SuBMLM7421JgqUmttw@mail.gmail.com>
Hi all, the taskforce chairs have gone through the feedback from the CFC [4] to pass the image description spec along for publication. We are now proposing a dispositive summary of comments received on our CfC [4] for Objections to Publish an FPWD for long textual descriptions on images and are asking the group to consider the following resolutions to the issues raised. Silence will be considered assent, but positive responses by [Friday 20thDecember, 23:59 EST] are preferred: *Technical issues:* Aside from the expressions of support, the accessibility taskforce has received one clear objection and several questions about the longdesc proposal. A new draft has been published addressing the bugs raised[1]. The following resolutions are proposed for points raised other than those considered to be purely issues of process: 1. David McDonald stated that an example of an image with null alt text and a longdesc would contradict a WCAG technique. A bug was raised 20048 [1] to track this. In the latest draft, the example has been removed. a. Resolution - Resolved fixed: Remove the example. 2. David also stated that longdesc URLs which were internal references to the page were a new feature and didn't work. Subsequent replies showed that they were part of the HTML 4 definition, that they had been implemented that way in pwWebspeak, Opera, iCab, the Firefox extension, and there were examples in the wild. However, current implementations using IE/JAWS, and some others do not handle this effectively. a. Proposed Resolution – Resolved Invalid: Keep the HTML 4 definition. State that implementations which do not recognise internal page references are incorrect. 3. James Craig and Matt Turvey both stated that an image description should be available to all users. Nobody disagreed, and several people agreed. A bug was raised[3] to track this. The proposed specification already requires user agents to enable users, as well as assistive technologies, to access the functionality. The Opera, iCab and Firefox implementations all do this. The NVDA implementation was held back with the explicitly stated hope that the functionality would be made available to all users through the browser. a. Proposed Resolution – Resolved Fixed: The recent update to the specification addresses this by more clearly stating that the requirements apply to all users, not just assistive technology. b. If this is still unclear in the specification, please provide specific editorial suggestions to improve it. 4. Matt Turvey suggested that the use case of making it straightforward to teach the use of description mechanism be removed, because it could be interepreted in a way that casts a bad light. a. Proposed Resolution- Resolved Won’t Fix: The use case has value and should be retained. b. If there are ways to reduce the risk of wilful misinterpretation, please provide specific editorial suggestions to improve it. 5. Matt Turvey stated that poor implementation of longdesc means that it is more harmful than beneficial. Various responses have been made that while poor implementation is a known issue, the harm it may do is outweighed by the benefit of good implementations that exist. a. Proposed Resolution: Resolved Won’t Fix: This is a point in contention, and the case that longdesc is harmful has clearly not been proven. 6. Matt Turvey suggested that the specification could be changed to state that it should only be used in cases where the audience was controlled. a. Proposed Resolution- Resolved Won’t Fix: This restriction is unnecessary, and counter-productive. It should not be added to the specification. 7. Matt Turvey, James Craig, and Silvia Pfeiffer suggested the specification could be changed to state that longdesc is obsolete. a. Proposed Resolution- Resolved Won’t Fix: In a specification of a single feature, this makes no sense. The question might be relevant to the HTML Working Group if it wants to consider incorporating this extension directly into the HTML specification. *Issues of process:* The following resolutions are proposed for points raised [5] considered to be purely issues of process: 1. Matt Turvey suggested we haven't addressed the objections from the original HTMLWG poll and decision. a. Proposed resolution - Invalid: The decision was overturned. The question of whether a draft makes a reasonable FPWD does not depend on it meeting all technical objections, and therefore it is reasonable to file a bug for any given technical issue (as has been done in some cases already) and proceed with publishing. 2. Matt Turvey suggested None of the use cases (except Teaching Accessible Development)appear to specifically require longdesc. a. Proposed resolution - Invalid: Use cases do not require a specific solution. They lead to requirements, and we standardise something that meets those requirements. 3. Matt Turvey suggested that the use cases can already be better addressed with existing, widely supported techniques. a. Proposed resolution - Invalid: It is clearly possible to meet any given use case's requirements, and even a subset of all of them, with many kinds of solutions. There is no reason an alternative cannot be proposed as an extension specification. We are not discussing other proposals, but whether it is reasonable to publish a draft of one proposed solution. 4. Matt Turvey suggested that if there is a use case that specifically requires programmatic determinability of a long description link as distinct from a normal link, but is not satisfied by using rel=longdesc, this should be included. a. Proposed resolution - Invalid: Use cases should identify problems that need solutions, not be reverse-engineered from solutions (nor from hypothetical proposals for solutions). There is no reason an alternative cannot be proposed as an extension specification. We are not discussing other proposals, but whether it is reasonable to publish a draft of one proposed solution. 5. Matt Turvey suggested that as Geoff Freed is currently compiling evidence for the Task Force that some educational publishers might be about to start using longdesc. It may be worth waiting until we have that evidence available. a. Proposed resolution - Invalid: If this were the only evidence, or critical for a decision on whether to proceed to Recommendation, it might be worth waiting for it. Since this CfC is about developing the specification as a Working Draft, it is unnecessary to wait for all possible knowledge before moving forward. 6. Matt Turvey suggested that as Sam Ruby previously suggested a course correction may be required on longdesc, citing the absence of correct longdesc usage in Steve Faulkner's survey of the top 10,000 website home pages. Is this spec the kind of course correction that will convince HTMLWG members to support longdesc? a. Proposed resolution - Invalid: It's difficult to guess if Sam is right. What Sam Ruby suggested is not a process requirement, and as understood he didn't even suggest this was the chairs' opinion, just an idea of his own. Therefore not publishing a draft of the spec seems unlikely to help determine the answer to Matts question. References: [1] http://dvcs.w3.org/hg/html-proposals/raw-file/1f251fcbe363/longdesc1/longdesc.html [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20048 [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20117 [4] http://lists.w3.org/Archives/Public/public-html-a11y/2012Nov/0091.html [5] http://lists.w3.org/Archives/Public/public-html-a11y/2012Nov/0152.html On behalf of the task force chairs: Janina, Steve and Chaals -- with regards Steve Faulkner Technical Director - TPG
Received on Thursday, 13 December 2012 22:55:40 UTC