resolutions for longdesc spec...

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 Wednesday, 13 February 2013 11:12:56 UTC