Corrected HTML-A11Y Task Force Consensus Decision and Request to Publish

Colleagues:

With apologies I am resending this announcement and publication request
to correct the URI for the longdesc extension specification. The correct
URI incorporates changes the Task Force accepted as a result of our
first CfC process as noted in item IV below.

This email is to announce a consensus in the HTML-A11Y Task Force to
request First Public Working Draft (FPWD) publication of an HTML
extension specification for a long text description mechanism as an
attribute to the image element, and named longdesc.

The specification is provided at:

        https://dvcs.w3.org/hg/html-proposals/raw-file/1f251fcbe363/longdesc1/longdesc.html

We hereby request publication approval from the HTML and WAI_PF Working Groups
as provided under Plan 2014.  We further request PF and HTML Staff Contact
assistance to insure all necessary copyright, status, and other pertinent W3C
notices are incorporated in this document prior to publication.

The Task Force decision to call for a consensus on publishing this specification as an FPWD is logged at:

http://www.w3.org/2012/11/15-html-a11y-minutes.html#item01

Additional steps performed to validate the Task Force consensus for this
request include:

I.	A Call for Consensus to publish this specification as a FPWD was posted
on the TF list on 20 November last:

http://lists.w3.org/Archives/Public/public-html-a11y/2012Nov/0091.html

II	A draft summary of objections received together with comments on the
disposition of each objection received was prepared (as discussed by the TF in
teleconference as minuted at
http://www.w3.org/2012/11/29-html-a11y-minutes.html#item04 and following). This
summary was published to the TF list with request for concerns and corrections
should our summary incorrectly represent any aspect of the objections received:

http://lists.w3.org/Archives/Public/public-html-a11y/2012Dec/0087.html

III.	A second draft summary of objections and their dispositions was announced:

http://lists.w3.org/Archives/Public/public-html-a11y/2013Jan/0112.html

There were no further objections to this summary from commenters.

III.	The Task Force Co-Chairs and relevant Domain Leads addressed two
remaining editorial clarifications in the summary of dispositions to objections
received.  As agreed by the Task Force (and noted in the 14 February minutes at
http://www.w3.org/2013/02/14-html-a11y-minutes.html),  final (48-hour) call for
any remaining editorial concerns was published twice, on February 13 and again
on February 14,  at:

http://lists.w3.org/Archives/Public/public-html-a11y/2013Feb/0053.html
http://lists.w3.org/Archives/Public/public-html-a11y/2013Feb/0056.html

There being no objections to this final draft, it is included below in this
email as a Task Force Consensus statement.

IV.	resolutions for longdesc spec...
	Summary of Objections and their Dispositions

A.)	Technical Objections Received

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.

B.)	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.

This request is sent on behalf of the HTML-A11Y Task Force Co-Chairs:
Janina, Charles, and Steve


-- 

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 Wednesday, 20 February 2013 19:41:41 UTC