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

Paul:

I'm working on the email request right now. Expect it a bit later today.

Janina

Paul Cotton writes:
> > 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

-- 

Janina Sajka, Phone: +1.443.300.2200
   sip:janina@asterisk.rednote.net
  Email: janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Protocols & Formats http://www.w3.org/wai/pf
 Indie UI   http://www.w3.org/WAI/IndieUI/

Received on Monday, 18 February 2013 21:05:30 UTC