- From: James Craig <jcraig@apple.com>
- Date: Fri, 18 Jan 2013 09:25:43 -0800
- To: Steve Faulkner <faulkner.steve@gmail.com>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, Matthew Turvey <mcturvey@gmail.com>
Thanks for clarifying Steve. I won’t speak for Matthew, but that’s a good summary of my comments on the longdesc call-for-consensus thread. James On Jan 18, 2013, at 2:13 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote: > Hi all, > > James raised a few issues with the text below, which i responded to by > email[1], but we (the chairs) thought it best to send a clarification > mail: > > James (and Matthew Turvey's) view is that any long description content > should be provided in a feature other than > @longdesc. > > James (and Matthew Turvey) requested that @longdesc be made 'obsolete > but conforming' in HTML5 rather than 'obsolete' > > The difference being that a valdiator should display a warning for > 'obsolete but conforming' features rather than an error. > > > As stated in [1] I encourage anybody to write an alternative extension > specification for an image description feature or methods to provide > image descriptions using existing HTML features, which may include a > conformance requirement pertaining to the @longdesc attribute. > > > [1] http://lists.w3.org/Archives/Public/public-html-a11y/2013Jan/0096.html > > regards > > SteveF (on behalf of the taskforce chairs) > > > > > On 13 December 2012 22:54, Steve Faulkner <faulkner.steve@gmail.com> wrote: >> 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 20th >> December, 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: >> >> 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 Friday, 18 January 2013 17:26:19 UTC