Re: Call for Consensus (CFC) to move forward the HTML5 Image Description Extension spec for publication (FPWD)

Chair hat off.

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

> On 20 November 2012 12:15, Steve Faulkner <faulkner.steve@gmail.com>  
> wrote:
>
>> We are calling for consensus on the HTML5 Image Description Extension
>> specification [1]
>
>> Is this specification ready to be put forward by the Task force to the  
>> HTML WG and the Protocols and Formats WG for consideration for
>> publication as a first public working draft (FPWD)?
>>
>> [1]
>> http://dvcs.w3.org/hg/html-proposals/raw-file/4893614e89f2/longdesc1/longdesc.html
>
> I object to publishing this specification as FPWD:
>
> * None of the use cases (except Teaching Accessible Development)
> appear to specifically require longdesc.

Sure. The point of developing use cases, and extracting requirements from  
them, is to avoid starting with a solution and looking for a problem for  
it to solve. So there is no reason for the use cases to specifically  
require longdesc.

> 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 all kinds of solutions. If you think there  
is an alternative that meets the use cases and requirements please provide  
it as a proposal. Demonstrating why unmet requirements and use cases  
should be discounted is a reasonable part of an argument for any such  
proposal, of course.

> * The Teaching Accessible Development use case could be perceived as
> arguing for imposing a complexity tax on people with disabilities
> solely for the benefit of the accessibility training industry. I'm not
> sure this is a message we want to promote.

Lots of things "could be perceived" as arguing all kinds of things. To a  
certain extent we can improve our wording to reduce the likelihood of  
misunderstanding, as I propose for the discoverability requirement below.  
But lots of things can also be wilfully misinterpreted, and it is not  
clear that we can, let alone should, aim for a wording so watertight that  
this possibility does not exist. Letting perfection be the enemy of good  
will destroy our ability to make progress in improving the web.

The intent is that Web developers need to learn their job. Their job  
includes providing for users who have a variety of needs, such as those  
which result from a disability. Reducing the cost of learning that part  
doesn't seem designed to support the accessibility training industry. It  
is actually intended to reduce the need for any such industry, by making  
accessibility simple enough for ordinary developers to understand without  
specialist training.

I believe this is a use case we want to promote. Do you believe otherwise,  
or are you merely concerned that the wording is too easily misinterpreted,  
and if so do you have a proposal to improve it?

> * People with cognitive impairments or low educational attainment,
> non-native language speakers, people with visual impairments who do
> not use AT but would benefit from an image description, people who
> appreciate reading a long description of a well-known artwork in
> addition to viewing the image, etc, cannot easily access an
> imperceivable longdesc link and face being completely locked out.

Quite true. The requirement "discoverability" assumes that user agents  
will present the option of reading the description to all users. But  
reading it again, that is probably not stated clearly enough. I filed a  
bug against the spec - https://www.w3.org/Bugs/Public/show_bug.cgi?id=20117

I believe there is a general consensus that longdesc should not only be  
available to AT users. That was the explicit reason that NVDA held off  
implementation, hoping that instead the functionality would be available  
 from the native browser UI, according to their comments on the relevant  
bug.

> Effective accessibility techniques should remove barriers to access,
> not introduce new barriers.

Agreed. I would be surprised if there is anyone who did not agree to that  
statement in either this group or the wider HTML WG.

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

In the absence of a clear proposal to use rel=longdesc to meet the use  
cases and requirements this seems like a technically weak objection. As  
noted above, there may be numerous possible alternatives, and you are  
welcome to write them up as formal specification proposals.

Without claiming that existing implementation in software, authoring  
systems, workflows, and educational material should be protected at all  
costs, the requirement "Backward Compatibility" (a SHOULD rather than MUST  
in the spec, to avoid us being unnecessarily constrained by a sunk cost)  
seems to be one reason rel=longdesc may not be a good solution.

> * 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, I don't see why  
we need to wait. In addition Geoff has 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.

> * We haven't addressed the objections from the original HTMLWG poll
> and decision, in particular:
>
>     "ample evidence that longdesc has been so badly abused in practice
> that preserving it gives the pretense of serving accessibility while,
> in fact, not providing it."

People with significant practical experience in accessibility, well aware  
of the extent of misuse, believe that longdesc does in fact enhance  
accessibility - and have implemented support for it.

That suggests that the evidence does not support the conclusion.

>     "no stated reason that this feature will actually be used more in
> the coming 10 years than it has in the past 10 years"

If this were a request for a Recommendation, that would be a convincing  
reason not to proceed. This request is for a first public working draft.

Increasing implementation over the last five years, in the context of  
substantial public discussion of the issue, suggests that longdesc  
implementation and use may accelerate.

>     "Many objected to inclusion of features in the language that have
> proven to be problematic and don't support any known use cases."

Known use cases have been listed.

> http://www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/results
> http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html

These references are to a decision that was subsequently overturned by the  
people who made it, reopening the issue. Which was subsequently passed to  
this Task Force with the explicit statement
[[[
We ask those that oppose instating a longdesc attribute to focus on  
producing a better solution, and meanwhile not oppose those that wish to  
pursue longdesc via an extension spec or making progress towards  
demonstrating that it meets the identified CR exit criteria.
]]]

The present discussion is not about whether W3C should recommend longdesc,  
merely about making a spec for it good enough to be something that could  
be proposed as a Recommendation.

> * 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. The low amount of correct longdesc  
usage is a long-recognised problem, but solving it for either longdesc or  
proposed alternatives has proven difficult. There are many promising  
alternatives offered. I actively hope that something will prove so much  
more successful than longdesc that we stop trying to improve its  
specification and usage. In the meantime, "better" is better than  
"nothing", hence the effort to cleanly specify longdesc along the lines of  
actual implementation and give poor-quality implementations a reference to  
help them improve.

I find it hard to see how not publishing a draft of the spec will 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 is indeed a possible change. It bears on the validity of the use  
cases outlined, and authoring requirements, but appears to have no direct  
bearing on the technical details of the specification. If you actually  
want to propose this change, please file a bug. There are many possible  
changes we could make, but without a proposal there is little the group  
can do. If nobody is willing to make a proposal for some hypothetical  
change, it seems like a waste of the group's time to concentrate on that  
instead of on what they are actually doing.

cheers

Chaals

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

Received on Wednesday, 28 November 2012 11:54:16 UTC