RE: Resend Re: resolutions for longdesc spec...

> If there are no substantive objections to this in the next 48 hours we will request FPWD:

At last week's WG meeting Janina predicted that the TF would request a CfC on this spec early on Monday morning this week.  Status?

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-----Original Message-----
From: Charles McCathie Nevile [mailto:chaals@yandex-team.ru] 
Sent: Thursday, February 14, 2013 7:46 AM
To: public-html-a11y@w3.org
Subject: 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 Monday, 18 February 2013 20:53:40 UTC