Final thoughts (Was RE: General Response to the Accessibility Task force on Issues 90, 91, 93, 96, 97)

Shelley Powers wrote:
> 
> Regardless, the resolution from the group is a blanket statement that
> built-in good, bolt-on (ARIA) bad that doesn't take into account that
> this may not be true for every possible built-in element that could
> possibly exist.

NO-WHERE, *EVER* (!!!!), has anyone suggested that ARIA is bad, *except
you*. Continuing to perpetuate this myth in your own self-interest is
offensive to me.  I will return to an earlier email I wrote you on April
1st, 2010
(http://lists.w3.org/Archives/Public/public-html/2010Apr/0049.html)

	"There is nothing *wrong* with ARIA, but from the get-go ARIA has
always
been considered a bridging solution, as it essentially perpetuates the
'bolt-on' philosophy of Accessibility on the web."

ARIA IS NOT BAD! Continuing to suggest or allude otherwise is to
perpetuate a untruth that is unacceptable. 



> It also doesn't take into account the fact that there
> are costs to each new element, and that the costs to all communities
> may outweigh the perceived benefit to one community. Especially when
> there are alternatives to the elements.
>
> The Accessibility group fell back on a Directive, rather than
> carefully weight the costs/benefits of each element. At least, weight
> the costs/benefits with the general population of either the HTML
> Accessibility group, or the HTML WG.

You seem mighty quick to draw conclusions on little to no data. How do you
reach the conclusion that the costs and benefits were not weighed by the
Accessibility Task Force? That web accessibility specialists have never
given this any thought at all? 

The cost - the weight of whether we should rely on inherent versus
associated accessibility semantics - is something that we've discussed
internally for years; much longer than you've been part of this or any
other accessibility related discussion. We know, by shared experience and
through thoughtful informed discussion, that inherent semantics are
"better" than associated semantics, since should the association become
broken _for whatever reason_, the damage done is significant - often
critical; for some it is in fact Draconian Failure. 

Think about the very real cost of that. 

The Accessibility Task Force recently grappled with whether an image that
was missing alt text should be generating a Warning or an Error. It is an
excellent example of how "associated" data, the so-called 'hidden' data,
can be detrimental to accessibility. From the perspective of
Accessibility, an image element that is missing alt text is fundamentally
broken - it is incomplete, it does not work for a large group of
end-users, and it is an equivocal failure. But the problem is, the value
string for @alt is often 'hidden' to the majority of sighted users, and
<img> without @alt, even if non-conformant, will continue to render in the
browser window. Sadly there is no other way of imparting the 'meaning' of
an image in HTML than through an association mechanism, be it @alt or
@longdesc, or now via ARIA mechanisms. However all of these are still
association mechanisms, and if they are broken (and frequently are), we
have catastrophic fail for some (despite the on-screen rendering of the
image). The cost of that is *extremely* high w.r.t. accessibility.

ARIA is, in many ways, like @alt: it is a method that when done right -
when the association is properly applied - makes something that would
otherwise be inaccessible, accessible. But like @alt, if for whatever
reason the association is broken, then the <foo> that you applied your
ARIA to becomes (returns to being?) inaccessible. There is a cost there
too, and one that is extremely high from our perspective. It is one we
have to live with (just like the cost of missing @alt) as in some
instances there really is no other choice, but if we can do something
about reducing that cost, we should, and for most of us, we will. This
does not suggest however that ARIA is bad, or wrong, or less than useful -
far from it. But if we are to be honest about it, ARIA is second best if
we can do better, but extremely good when we cannot.

Suggesting that we have not thought about this in depth and over time
simply illustrates that *you* have not thought about this in depth or over
time, at least not from the perspective of what ensuring content
accessibility really means.

> 
> I'm sorry, but that's so vague as to be almost useless. I would hope
> the co-chairs would not consider that an effective rationale or
> statement of purpose. "make them better" -- in what way? How? When?
> Did you provide alternatives to "make them better" in the
> counter-proposals? No, you argued for the status quo. Support for the
> status quo (zero edits) and "make them better" is an oxymoron.

As a co-signatory to the Counter-Proposal
(http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements) I am not
convinced that there are any issues with these new elements. However if
you or others are concerned about parts of them, then make proposals to
*improve* them - the solution is not to just dump them and walk away,
arguing that ARIA has it covered and we should be happy with that. 

I'm *not* happy with that, as while I totally value and appreciate what
ARIA has contributed towards providing accessibility, I also acknowledge
that there are imperfections with ARIA that we cannot address - it is by
nature and design an associated mechanism for accessibility, as opposed to
an inherent mechanism. If you think there are flaws with the new elements,
propose a positive step towards 'making them better'. Suggesting we
discard them because you discovered how wonderful and "fun" ARIA was "...a
few weeks back" is not the answer.
(http://lists.w3.org/Archives/Public/public-html/2010Apr/0028.html) 

> 
> "dumped in favor of the status quo" -- I would expect members of this
> group to provide the strongest and most detailed rational for either
> keeping the element, or removing it.

Shelley, you have not made a substantial case to me or others on why these
elements are wrong, nor (more importantly) have you suggested ways to
improve them. Your entire series of change proposals are to abandon them
in favor of what we have now - the status quo. 

First you argued from the perspective of "accessibility", reasoning that
this was the Achilles heel, as the editor used accessibility as his
justification for keeping these elements. When you generated near-zero
support from the accessibility community with that reasoning, you revised
your argument to one of "cost" and lack of current implementation and
support in the current user agents. Yet you have not really provided a
cost analysis one way or other to back your claims (outside of asserting
there is a cost), and the support and implementation in browsers of many
parts of the HTML Working Draft today remains checkered and inconsistent
across all the browsers and platforms - rendering that argument specious
as well; we all accept that HTML5 is still under development. You want
details and specifics, but come up significantly short on both yourself.


> And that the decisions of this
> group be based on these rationales, rather than popularity of the
> people,

Suggesting that the caring and intelligent people involved in this
discussion are in some kind of popularity contest is offensive to me. For
shame.


> or based on some over-broad generalized directive, that
> frankly, will probably end up causing more problems than it solves.

That is a wonderfully opinionated statement. I could use the very same
statement to counter your proposals; that accepting your Change Proposals
would "...probably end up causing more problems than it solves." That you
cannot see this double standard is quite frustrating. 

The rationale being used is the one I've attempted on numerous occasions
to explain to you: "bolting on" accessibility is a second choice over
inherent accessibility, regardless of how clever ARIA is. If you cannot
accept that statement of fact, then we are indeed at a deadlock. (This is
also not about choosing one over the other, we want both, but prefer the
better inherent solution whenever possible)

> 
> Some people did, though, unfortunately, in some form of "grouped"
> counter-proposal. However, at least it gives me something I can
> respond to.

I was one of "those people". That 'grouped' Counter-Proposal was done with
the consent and agreement of the HTML WG Chairs. It acknowledges that your
Change Proposals all address a larger fundamental issue. If you have issue
with that (you indicated earlier that you did not), then take that up with
the HTML WG Chairs - the Counter-Proposal was issued in good faith using
an approved mechanism. 

> 
> The Accessibility task force did not provide details. I have nothing
> to respond to, no discussion can follow. It is a wall--all I can do is
> bang my head against it.

The Task Force 'details' have been provided to you
(http://www.w3.org/2002/09/wbs/44061/200404_ftf-proposals/results#xq5).
The Task Force *DID NOT* submit a Counter-Proposal, simply issued their
Recommendation based upon internal (yet still public) discussion and
deliberation, as is their right, mandate and choice. You were (and still
are) free to become a member of the Task Force - the only criteria being
that you are also a member of the HTML WG (due to the patent/license
agreement).

The Agenda for the Face-to-Face meeting in Birmingham indicated that your
Change Proposals would be discussed - you were welcome to participate
personally or virtually (many dialed in from North America) - the IRC
channel minutes was also made publicly available, and those minutes are
still available today. The Task Force's Draft Proposal was circulated
amongst the members of the Task Force, and we had 3 days to respond;
either via this list or in the Survey Tool itself. The HTML5 A11y Mailing
List (as well as public-html) has also seen some additional discussion and
input on the subject - I myself have contributed a number of emails on
both lists attempting to explain to you (with increasing frustration) the
reasoning and justification from the accessibility community's
perspective, as you also continue to admit you are not an accessibility
expert yourself. 

If it is a 'wall' to you, it is in part because you continue to see it and
treat it as a wall.

> 
> Now there we see a new fact that should stop us. There are other more
> "interesting" things that should take time, rather than these less
> interesting, less "important" discussions.

"Interesting" is your word, not mine nor anyone else's. "Important" is
also subjective: you have failed to convince anyone I know that there are
real problems with the new elements, and your proposed 'resolution' of
said alleged problems is not to address those problems, but to abandon the
elements outright.

If you can show why there are flaws with these elements *PLUS* a positive
way forward (and not a resigned way backward) then the issues might gain
priority within the ongoing list of priorities the Task Force is dealing
with - here however I do not speak for the Task Force, this is simply my
observation.  Yet you have done neither to date as far as I can tell; you
simply argue that "we haven't thought about this", that we are a "wall" to
you, that everyone is ganging up on you in some form of popularity
contest, and that these new elements are 'wrong', that they 'cost' too
much and should be abandoned. You entire approach has been negative from
the onset.

> 
> > Perhaps you Laura would be interested in taking on this additional
> work?
> >
> 
> That's inappropriately putting someone on the spot. Such a statement
> can be seen as an attempt to quell discussion.

Laura asked a direct question to the Task Force Chairs that cannot be
answered by them. We are all volunteers who will take on what we deem to
be important to *us* (individually), and asking if "someone" is going to
do the work ignores that the Chairs cannot 'task' anyone to do so -
somebody must step forward and claim the issue(s). That can be Laura, that
can be you, that can be anyone reading this who feels you might have a
point.

I am now quite done discussing this with you Shelley. I have tried (with
increasing frustration) to explain this to you from the perspective of the
overall accessibility community - however I dare not speak for all and if
anyone is reading this and disagrees with what I have written please speak
up - I do not claim to own the "One Truth". However I personally *have*
given this much thought, and weighed the pros and cons of your proposals,
and I *have* spent the time and effort I felt necessary to address your
assertions. I *have* engaged in discussion, and not sought to quell it,
and I remain convinced that the Counter-Proposal I participated in is the
better way forward.

The cast has been set: there are two visions currently before the larger
Working Group regarding these semantic elements, there is a declared
deadline of May 6th for continued discussion and alternative proposals,
and there is a Consensus mechanism within the W3C that provides for a
means of quelling both filibuster and addressing minority dissent within
the overall goal of Consensus. Each will have their day.

Respectfully

JF

Received on Thursday, 22 April 2010 21:46:47 UTC