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

Hi all,

James raised a few issues with the text below, which i responded to by
email[1], but we (the chairs) thought it best to send a clarification
mail:

James (and Matthew Turvey's) view is that any long description content
should be provided in a feature other than
@longdesc.

James (and Matthew Turvey) requested that @longdesc be made 'obsolete
but conforming' in HTML5 rather than 'obsolete'

The difference being that a valdiator should display a warning for
'obsolete but conforming' features rather than an error.


As stated in [1] I encourage anybody to write an alternative extension
specification for an image description feature or methods to provide
image descriptions using existing HTML features, which may include a
conformance requirement pertaining to the @longdesc attribute.


[1] http://lists.w3.org/Archives/Public/public-html-a11y/2013Jan/0096.html

regards

SteveF (on behalf of the taskforce chairs)




On 13 December 2012 22:54, Steve Faulkner <faulkner.steve@gmail.com> wrote:
> 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 20th
> December, 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:
>
>  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 Friday, 18 January 2013 10:14:23 UTC