RE: Issue 30 - longdesc

Sam Ruby wrote:
> 
> I don't understand the purpose of these clarification requests.

Let me be as clear as I can be here Sam. 

In the Chairs response to Issue 30 you have specifically referred to
measurable metrics (and more specifically "rapidly", "growth",
"widespread", "interoperable" and "implementation"), without further
defining those metrics or how they are measured. The Chairs expect us to
know what those metrics represent, yet I have repeatedly stated I do not
understand what they represent. 

I wish to have clear, unambiguous, measurable and accountable definitions
of those 5 terms - terms the Chairs have previously used when explaining
what they expect to see to re-instate @longdesc into the specification, so
that everyone - proponents and opponents - understands the "rules", the
expectations, and how they will be assessed. What about this request is
difficult to understand? The bottom line here is that the Chairs need
"enough" evidence to justify reversing the current decision, but nobody
knows how much "enough" is.

ONE MORE TIME:

Let's focus on "rapid growth" for a minute. I will argue that, with the
emergence late last year of a WordPress plug-in for @longdesc, we've seen
growth, and that since the plug-in emerged mere weeks *after* the Chairs
decision, that it has come rapidly.  Another TF member might argue that
it's only one plug-in, and that it's taken this many years for it to
surface, so it is hardly "growth", and far from rapid.  

Which is it? I mean, it's one or the other, right? It can't be both... but
maybe it's neither. Who knows? Do the Chairs? If the answer to that final
question is no, then where are we? How will we stop this ping-pong game?
(for surely, if/when the chairs reverse the decision, a whole other round
of objections and protestations will start that the Chairs are once again
wrong, made a bad decision, etc., etc., etc.) So we must trust that the
Chairs *do* know. I am asking that you share that information with us, so
we too can know if we have successfully, unequivocally met the requirement
of "rapid growth"; and if we have, then our opponents cannot cry foul down
the line as the bar has been set and understood by all.

The Chairs have previously counseled us to take our time, and get this
right, as we will likely only get one more chance at it, yet when we seek
to ensure we get it right by asking how our efforts and results are to be
measured and evaluated, you won't give us (me!) a direct answer.  It seems
to me you are using the 'pornography' answer - you can't tell me what it
is, but you'll know it when you see it.  I for one can't accept that
without understanding what you consider pornographic. *Especially* since
we only have one last chance to show it to you. 


> 
> We stated that the issue can be reopened if one or more of these
> conditions are met.  I have already said that I believe that the
> conditions have been met.  What more clarification do you need?  "What
> will make a compelling case?"  The only possible answer to that is "a
> case that is stronger than the objections that may be raised in
> response to the proposal".

Correct, and it seems that it will be the Chairs judging those objections,
thus I am seeking to understand by what criteria you will be judging them
by, as in the past what I (and likely others) took for granted as "givens"
where summarily dismissed by the Chairs as weak.

Returning to the Chairs original response, the Review of Arguments
presented stated:

Implementation: 

"... No criteria was provided for the adjective "successfully"..." 
- so, can we get a definition of "successfully" so that all involved
understand what you mean by this? How are you measuring success?

"... Overall, it was found that this while this attribute is implemented,
it is not implemented widely..." 
- The Chairs acknowledged the fact that @longdesc is implemented, but
apparently not "enough" to meet the measure of "widely". So can we get a
measurement of what you consider "widely"? And while we are at it, can we
get a definition of "implementation", given that the majority of Screen
Readers *at the time of the decision* supported @longdesc, and all
browsers then, as well as today, expose the @longdesc attribute and value
in the DOM, and thus to all the OS accessibility APIs! If this is not
enough, what more is expected? 

"This necessarily makes this objection a weak objection." 
- I for one am still trying very hard to understand how this was deemed a
weak objection. 

I think it is safe to say that we had already determined @longdesc
"functionality" was currently supported by the majority of screen readers
(certainly *more than 2*), those AT Tools were "successfully" exposing
@longdesc content to their users while using *at least 2* different
browsers (where success = announcing the presence of a longer description
to the user and affording them choice to hear that longer description or
not - exactly as it was designed and envisioned to do). Finally the
decision noted *at least 2* content editing tools (one an embeddable
WYSIWYG, the other a stand-alone tool) that "successfully" allowed authors
to both add the @longdesc attribute to images when required, and to author
those long descriptions.

By formal W3C measure, we had met the requirement of "...demonstrate two
interoperable implementations of each feature"
(http://www.w3.org/2005/10/Process-20051014/tr.html#cfr) in browsers, in
AT tools, and in authoring tools, yet the Chairs called these arguments
"weak". 

What and why was any of the above "weak"? I have asked these questions
numerous times, and all I get back from you Sam is a hixian "I don't
understand". 

You want to know why I keep asking for clarification? It's because when
@longdesc meets implementation criteria that is formally offered as
sufficient criteria for moving an *entire specification* from CR to
Recommendation (2 independent implementations) the Chairs called it weak.
How can I and others then "strengthen" our arguments to make them "strong
objections" to the removal of @longdesc? Our mistake last time was in
assuming we shared common understandings around terms like
"implementation" and "success" - apparently we didn't - and I am seeking
to ensure we don't make the same mistakes again. So I want it all spelled
out in black and white for all to see and know.  What is hard to
understand about that?

We *ALL* need this to be an objective exercise, and not a subjective one.
Today it is not objective.


> 
> I do *not* recommend that you spend conference call time requesting
> clarifications

Thank you for your recommendation, however I stand by my request to have
this added to the agenda of next week's Accessibility Task Force
conference call. If the W3C can come up with a fixed metric of "2
independent implementations" to move an entire specification from
Candidate Recommendation to Final Recommendation, then surely we can get
fixed metrics on what is required to ensure @longdesc remains in HTML5 -
metrics we either successfully meet or fail to meet - but clear,
unambiguous metrics none-the-less. This may seem to you to be a
less-than-productive use of our time, but I assure you that for some of
us, it is not.

JF

Received on Friday, 7 January 2011 03:13:00 UTC