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

Hi Dave, noted, you can blame Chaals for the mispelling :-)

On 14 December 2012 02:25, David MacDonald <david100@sympatico.ca> wrote:

> Just one thing Steve... I’m MacDonald not McDonald... us Canadians with
> Scottish heritage are sensitive about that stuff :)****
>
> ** **
>
> Cheers****
>
> David MacDonald****
>
> * *
>
> *Can**Adapt* *Solutions Inc.***
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
> www.Can-Adapt.com <http://www.can-adapt.com/>****
>
> ** **
>
> *From:* Steve Faulkner [mailto:faulkner.steve@gmail.com]
> *Sent:* December-13-12 5:54 PM
> *To:* HTML Accessibility Task Force
> *Subject:* Call for Consensus on resolutions to Objections to Publish an
> FPWD for long textual descriptions on images - due Friday 20th December,
> 23:59 EST****
>
> ** **
>
> 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****
>
>  ****
>
>
> ****
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html