Process objections to FPWD

Hello,

Chair hat still off.

I believe that the following subset of Matt Turvey's objection to  
publication are based on Process, not technical issues. We agreed last  
week to pass such issues to the HTML WG.

I believe they should not hold up the Publication of a Working Draft. I  
have therefore proposed reasons for rejecting each point raised, and hope  
we can agree on these at the meeting today.

On Wed, 28 Nov 2012 03:00:54 +0400, Matthew Turvey <mcturvey@gmail.com>
wrote:

> * None of the use cases (except Teaching Accessible Development)
> appear to specifically require longdesc.

Use cases do not require a specific solution. They lead to requirements,  
and we standardise something that meets those requirements.

> It seems these scenarios can already be better addressed with
> existing, widely supported techniques
> eg:
>
> <a href="description"><img src="image" alt="*the purpose of the link*"
> style="border:0"></a>
>
> or:
>
> http://www.w3.org/TR/WCAG-TECHS/G73.html
> http://www.w3.org/TR/WCAG-TECHS/G74.html

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.

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

Use cases should identify problems that need solutions, not be  
reverse-engineered from solutions (nor from hypothetical proposals for  
solutions).

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

If this were the only evidence, or critical for a decision on whether to
proceed to Recommendation, it might be worthwaiting 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.

In addition, Geoff already stated that he may or may not be able to
provide public evidence, but has stated that some publishers are
using it, and that some more are planning to do so.

> * 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?

It's difficult to guess if he is right. What Sam Ruby suggested is not a  
process requirement, and as I understand it he didn't even suggest this  
was the chairs' opinion, just an idea of his own.

Not publishing a draft of the spec seems unlikely to help determine the  
answer to your question.

> * One possible course correction could be spec'ing longdesc only for
> use in walled-gardens: i.e. that longdesc should only be used in
> closed environments, where accessibility specialists can ensure users
> have the required software installed, can train users to access
> longdesc and can control the quality of the walled-garden's longdesc
> content, and it should not be used on the Web.

This idea appears to have no direct bearing on the technical details of
the specification.

Unless it is proposed, it is just a "possible change" as stated. The fact  
that a spec can be changed is no reason to hold up publication of a draft.

cheers

Chaals


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Thursday, 6 December 2012 16:02:30 UTC