W3C home > Mailing lists > Public > public-html-a11y@w3.org > December 2012

Call for Consensus on resolutions to Objections to Publish an FPWD for long textual descriptions on images - due Friday 20th December, 23:59 EST

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Thu, 13 Dec 2012 22:54:27 +0000
Message-ID: <CA+ri+VmTbY_rkC+2aBU9GPqsO0PMBLF0SuBMLM7421JgqUmttw@mail.gmail.com>
To: HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi all,

the taskforce chairs have gone through the feedback from the CFC [4] to
pass the image description spec along for publication. We are now proposing
a dispositive summary of comments received on our CfC [4] for Objections to
Publish an FPWD for long textual descriptions on images  and are asking the
group to consider the following resolutions to the issues raised.

Silence will be considered assent, but positive responses by [Friday
20thDecember, 23:59 EST]
are preferred:

*Technical issues:*

Aside from the expressions of support, the accessibility taskforce has
received one clear objection and several questions about the longdesc
proposal. A new draft has been published addressing the bugs raised[1]. The
following resolutions are proposed for points raised other than those
considered to be purely issues of process:

   1.  David McDonald stated that an example of an image with null alt text
   and a longdesc would contradict a WCAG technique. A bug was raised 20048
   [1] to track this. In the latest draft, the example has been removed.

a.  Resolution - Resolved fixed: Remove the example.

2.  David also stated that longdesc URLs which were internal references to
the page were a new feature and didn't work. Subsequent replies showed that
they were part of the HTML 4 definition, that they had been implemented
that way in pwWebspeak, Opera, iCab, the Firefox extension, and there were
examples in the wild. However, current implementations using IE/JAWS, and
some others do not handle this effectively.

a.  Proposed Resolution – Resolved Invalid: Keep the HTML 4 definition.
State that implementations which do not recognise internal page references
are 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. 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.

a.  Proposed Resolution – Resolved Fixed: The recent update to the
specification addresses this by more clearly stating that the requirements
apply to all users, not just assistive technology.

b.   If this is still unclear in the specification, please provide specific
editorial suggestions to improve it.



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.

a.  Proposed Resolution- Resolved Won’t Fix: The use case has value and
should be retained.

b.  If there are ways to reduce the risk of wilful misinterpretation,
please provide specific editorial suggestions to improve it.



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, the harm it may do is
outweighed by the benefit of good implementations that exist.

a.  Proposed Resolution: Resolved 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.

a.  Proposed Resolution- Resolved Won’t Fix: This restriction is
unnecessary, and counter-productive. It should not be added to the
specification.



7.  Matt Turvey, James Craig, and Silvia Pfeiffer suggested the
specification could be changed to state that longdesc is obsolete.

a.  Proposed Resolution- Resolved 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.



*Issues of process:*

The following resolutions are proposed for points raised [5] considered to
be purely issues of process:

1.  Matt Turvey suggested we haven't addressed the objections from the
original HTMLWG poll and decision.
a.  Proposed 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.

2.  Matt Turvey suggested None of the use cases (except Teaching Accessible
Development)appear to specifically require longdesc.
a.  Proposed resolution - Invalid: Use cases do not require a specific
solution. They lead to requirements,  and we standardise something that
meets those requirements.

3.  Matt Turvey suggested that the use cases can already be better
addressed with existing, widely supported techniques.

a.  Proposed 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.

4.  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.

a.  Proposed 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.

5.  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.

a.  Proposed 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. Since this CfC is about developing the
specification as a Working Draft, it is unnecessary to wait for all
possible knowledge before moving forward.

6.  Matt Turvey suggested that as Sam Ruby previously 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. Is this spec the kind of course correction that will convince HTMLWG
members to support longdesc?

a.  Proposed resolution - Invalid: It's difficult to guess if Sam is right.
What Sam Ruby suggested is not a process requirement, and as understood he
didn't even suggest this was the chairs' opinion, just an idea of his own.
Therefore not publishing a draft of the spec seems unlikely to help
determine the answer to Matts question.



References:

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

[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20048

[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20117

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

[5]  http://lists.w3.org/Archives/Public/public-html-a11y/2012Nov/0152.html





On behalf of the task force chairs:



Janina, Steve and Chaals





-- 

with regards



Steve Faulkner

Technical Director - TPG
Received on Thursday, 13 December 2012 22:55:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 December 2012 22:55:41 GMT