RE: Notice of impending Formal Objection to Issue 30 Decision (@longdesc)

(cc list radically trimmed)

Sam Ruby wrote:
>
> specifically cited in the
> decision, was "no stated reason that this feature will actually be used
> more in the coming 10 years than it has in the past 10 years".

When did this become a criteria for implementation measurement? It is being 
used now in specific instances, and the _volume_ of usage should not be a 
criteria in determining usefulness. If it is being successfully used on n% 
of sites today, and would be used successfully on >n% tomorrow, is that 
enough? Even if it is n% + 1 is that not an increase? This is a nebulous and 
unhelpful response. (If volume alone is a criteria, how many useful and 
working examples do we have for <dfn>?)

What was stated in the "Conforming with Error" 
(http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescConformingWithWarning) 
proposal was:

 "A handful of sites (organizations for the disabled, government entities, 
nonprofits, etc) go far beyond the norm in trying to provide a good 
accessibility experience. [1] They may be relying on longdesc to improve the 
experience, and it would be disruptive to immediately make such content 
nonconforming." [2]

...and

 "Some laws, regulations and organizational policies may refer to longdesc 
by name." [3]

Breaking that down, I see:

[1] Acknowledgment of good (but unquantified) usage in the wild, and a tacit 
reference to those types of content producers who would be using @longdesc 
(presumably correctly) today. If they are now doing it 'right' (as opposed 
to either not doing it in the past, or doing it wrong in the past) then 
sheer logic would suggest that correct usage would increase over time. Does 
this assertion need to be quantified for validity? If we see a 10% increase 
of correct usage then we're good to go, but if it's only a 8% increase it's 
not enough? Why, and where was that previously suggested/stated? You state 
as a reason for rejection an undefined value point - what is enough 
"increased usage", exactly?

[2] Does the 'disruptive factor' not count? What is the Chairs' position 
here? That because in the past 10 years there have been mistakes we'll toss 
the baby out with the bath-water? What of backward compatibility? Or is that 
not important? Is the disruption of existing content and future authoring 
requirements really "weak"? According to whom? For those entities under this 
mantle, it is not weak, it is critical: to my knowledge and understanding 
this one decision now officially shuts out both Dutch and French developers 
(and possibly others) from using "HTML5 the Markup Language", until such 
time as their current national laws are revisited to remove the specific 
requirement to use @longdesc. Yet this is deemed "weak"?

[3] Acknowledgement of existing laws and policies (not named but understood 
to exist) that *SPECIFICALLY* names @longdesc as a requirement. Are we now 
hearing that to legitimize that claim we need to offer more proof by way of 
a list of laws and policies? Given the sensitivity of accessibility issues, 
at the very least the Chairs could have requested more specific details at 
any point in the discussion, including after the survey poll and during 
deliberations. If such a list alone is grounds to re-open this decision, 
then please specifically state as such, and I'm sure we can come up with a 
list.

The frustration here is that you wanted more detailed specifics from some of 
us, yet offer none back in return. You want "more" and "rapidly" without 
defining what they mean, yet consider weak the argument that some 
governments and other agencies will be negatively affected because we did 
not specify them by name or provide a list.

>
> Put in simpler terms, the chairs read of the sentiment of the working
> group is that "It don't work" is the basis for a stronger objection
> than
> "It says so right here".  That's true whether the original statement
> came from ECMA, the IETF, or even here in the W3C.

Who said "it won't work"? And where is that referenced in the decision? All 
I've heard and seen is that content authors have made mistakes in the past - 
there has never been any technical proof that the @longdesc mechanism won't 
work, and in fact in at least 2 browsers today if you author @longdesc 
correctly, it *DOES* work. So I for one reject that observation as both 
un-measurable and undefined, as well as patently false in its premise. The 
problem is not with the @longdesc mechanism, but rather with ill-informed 
developers in the past.

As a request to the Chairs - is there a *Technical* reason why @longdesc was 
rejected? Can we be privy to that data?

>
> Again, just so it isn't crystal clear: I am not saying that longdesc
> doesn't work or that WCAG doesn't matter.  I am saying that we asked
> for
> arguments and counter arguments, and evaluated the input that we were
> provided.
>
> Paths forward from this point (as listed in the decision itself):
>
>      * use cases that specifically require longdesc,

That has been provided in the past. In the interest of clarity, how many use 
cases are required above and beyond those already provided. I for one don't 
want to provide (for example) 3 use cases when you are expecting 5, and 
having them rejected because I did not provide enough. It does seem that the 
Chairs want measurable metrics.


>      * evidence that correct usage is growing rapidly and that that
>        growth is expected to continue, or

Again, please define 'rapidly'. And who judges whether 'rapid' is rapid 
enough? (Just because my investment portfolio does not see huge annual 
growth is no reason to abandon that investment strategy, as investment 
portfolios are often constructed with a long-haul payoff goal - the whole 
point is incremental growth, not runaway growth)


>      * widespread interoperable implementation.


W3C Process suggests that the measure of interoperable implementation is 
measured as "2" independent instances:

 "...the Working Group SHOULD be able to demonstrate two interoperable 
implementations of each feature" - 
http://www.w3.org/2005/10/Process-20051014/tr.html#cfr

I offer as proof Opera 10.6, and Firefox 3.5.11 (both installed on my 
current machine, and both supporting @longdesc in a near identical way, as a 
right-click contextual menu on my PC) How much more 'widespread' is required 
to satisfy the Chairs?

>
> Additionally, there is the path forward of a Formal Objection.
>

It appears that this may indeed be the required path, unless the Chairs are 
indicating that they are still open to revisiting their current decision. Is 
that what I am hearing?

JF

Received on Thursday, 12 August 2010 22:37:01 UTC