- From: John Foliot <jfoliot@stanford.edu>
- Date: Thu, 22 Apr 2010 14:46:12 -0700 (PDT)
- To: "'Shelley Powers'" <shelley.just@gmail.com>
- Cc: "'Laura Carlson'" <laura.lee.carlson@gmail.com>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'HTML WG'" <public-html@w3.org>
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