Resend Re: resolutions for longdesc spec...

Sorry, for some reason this email managed to pick up a different date and  
message id, so you may have missed it yesterday. It is the message in the  
archive that is linked from today's agenda...

cheers

Chaals

On Sat, 26 Jan 2013 22:20:33 +0100, Charles McCathie Nevile  
<chaals@yandex-team.ru> wrote:

> Hi,
>
> Sorry for the disgracefully long delay. Here are the resolutions we have  
> made, for a final check. If there are no substantive objections to this  
> in the next 48 hours we will request FPWD:
>
> 1. David McDonald stated that an example of an image with null alt text  
> and a
> longdesc would contradict a WCAG technique.
>
> Resolution: fixed.
> A bug was raised 20048 to track this. The example was removed.
>
> 2.  David also stated that longdesc URLs which were internal references  
> to
> the page were a new feature and didn't work.
>
> Resolution: Invalid.
> The HTML4 definition, which allows internal page references, has been  
> correctly implemented in pwWebspeak, Opera, iCab, the Firefox extension,  
> and other examples in the wild. Current implementations (such as  
> IE/JAWS, and some others) that do not recognize internal page references  
> should be cited as being 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.
>
> Resolution: Fixed.
> The latest specification draft addresses this by more clearly stating  
> that
> the requirements apply to all users, not just assistive technology. 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.
>
> 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.
>
> Resolution: Won’t Fix:
> The use case has value and should be retained.
>
> 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, any harm it may do is
> outweighed by the benefit of good implementations that exist.
>
> Resolution: 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.
>
> Resolution: Won’t Fix.
> This suggested restriction runs counter to the benefits of extending  
> longdesc to all users which was recognised as valuable by the Task Force  
> as noted in point 3 above.
>
> 7.  Matt Turvey, James Craig, and Silvia Pfeiffer suggested the
> specification could be changed to state that longdesc is obsolete.
>
> Resolution: 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, but
> that isn't even being discussed at this point.
>
> *Issues of process:*
>
> The following resolutions are for points raised that are purely issues of
> process:
>
> 1P Matt Turvey suggested we haven't addressed the objections from the
> original HTMLWG poll and decision.
>
> 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.
>
> 2P Matt Turvey suggested none of the use cases (except Teaching  
> Accessible
> Development) appear to specifically require longdesc.
>
> Resolution: Invalid.
> Use cases do not require a specific solution. They lead to requirements,
> and we standardise something that meets those requirements.
>
> 3P Matt Turvey suggested that the use cases can already be better
> addressed with existing, widely supported techniques. James Craig
> requested that "some mechanism other than longdesc be used".
>
> 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. Matt did not identify the relevant
> solutions he claims exist, and James did not provide an alternative
> proposal, nor explicitly object to publication of this FPWD.
>
> 4P 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.
>
> 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.
>
> 5P 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.
>
> 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. This CfC is
> about developing the
> specification as a Working Draft and it is unnecessary to wait for all
> possible knowledge before moving forward. Geoff Freed himself provided
> further evidence, and clarification that it is not worth waiting for
> information that is unlikely to be provided to a public mailing list.
>
> 6P Matt Turvey noted that Sam Ruby 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. Matt
> questioned whether this spec is the kind of course correction that will
> convince HTMLWG members to support longdesc.
>
> Resolution: Invalid.
> It's difficult to guess if Sam is right. What Sam suggested is not a
> process requirement, nor the chairs' opinion, just an idea of his own.  
> Not
> publishing a draft of the spec seems unlikely to help determine the  
> answer
> to Matt's (restatement of Sam's) question.
>
> for the TF co-chairs
> Chaals
>


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Thursday, 14 February 2013 12:46:11 UTC