W3C home > Mailing lists > Public > public-html-a11y@w3.org > December 2012

Re: Call for Consensus on resolutions to Objections to Publish an FPWD for long textual descriptions on images - due Friday 20th December, 23:59 EST

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Fri, 14 Dec 2012 02:38:05 +0100
To: "HTML Accessibility Task Force" <public-html-a11y@w3.org>, "Steve Faulkner" <faulkner.steve@gmail.com>
Message-ID: <op.wo99hrkty3oazb@chaals.local>
I support all the proposals (surprise :) ).

cheers

Chaals (speaking as Yandex rep, not as co-thingy)

On Thu, 13 Dec 2012 23:54:27 +0100, 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
>
>>
>
>
>
>


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com
Received on Friday, 14 December 2012 01:38:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 14 December 2012 01:38:39 GMT