- From: John Foliot <jfoliot@stanford.edu>
- Date: Sat, 1 Aug 2009 18:20:39 -0700 (PDT)
- To: "'Maciej Stachowiak'" <mjs@apple.com>
- Cc: "'Sam Ruby'" <rubys@intertwingly.net>, "'HTML WG'" <public-html@w3.org>, "'Manu Sporny'" <msporny@digitalbazaar.com>, "'Michael\(tm\) Smith'" <mike@w3.org>, "'Ian Hickson'" <ian@hixie.ch>
Maciej Stachowiak wrote: > > > On Aug 1, 2009, at 10:35 AM, John Foliot wrote: > > PFWG is perfectly entitled to make any non-normative recommendation it > wants about how best to deliver accessible content on the Web. I think > the particular statement you proposed would show poor judgment, but > that has nothing to do with who is making it. First off, I am not advocating making that statement, but instead using it to show how personal interpretation and opinion regarding the suitability of using or not using something is inappropriate. Ian and other members of WHAT WG are entitled to their opinion that using @summary causes "harm", to which I can only respond - don't use it. But today, WCAG 2 specifically states that content authors *should* use @summary, and since it is the responsibility of WAI and their working groups to speak authoratively on aspects of web accessibility, having a W3C draft specification that contradicts the current 'official' word is harmful, in that it causes confusion with authors who are not directly following these discussions. It is not Ian's place to overstep WAI, despite his best intentions toward improving accessibility, and if he strongly believes that continued usage of @summary is harmful, then he needs to make that case to WAI - just as he insists that others state their case to him when advocating their cases. Using his position of editor to short-cut this process in unacceptable, and is in fact the root of my objection. > Actually, I'm the one who suggested this change, not Ian. Ian > reluctantly agreed to my proposal, but I didn't see any reply at the > time from the stronger advocates of summary="". Since the draft is not > final and remains open to change, it's not too late to give your input > on this idea. > > If you think the change is not helpful, then please explain why. Don't > just complain about not being sufficiently consulted - I'm consulting > you (and your colleagues) now. And the requested feedback has come forward. However, I will reiterate *my* concerns once again: 1) the truthiness[1] of the 'proof of harm' has been disputed by many, and alone is not a reason for making the attribute obsolete. AS PFWG noted: "We note that accessibility is poorly supported on most web sites. The wider web is not an example of good practice." Sufficient examples of the proper use of @summary have been delivered to the working group to prove that it serves a unique and needed function today. 2) the current draft simply replaced Ian's proposal with your proposal with zero consultation, at the very same time that those who have concerns about @summary were working though the official process as prescribed by W3C to address their concerns. This is simply wrong from a fairness and procedural perspective. 3) I have stated numerous times that my bigger concern is with the fact that the HTML 5 editor has set himself above the W3C WAI when he writes in the draft specification to directly ignore WCAG 2 guidance and *not* use @summary (simply because his analysis of data and personal belief is that @summary is causing 'harm') This is fundamentally wrong - Ian may think of himself as the benevolent dictator of WHAT WG, but again I maintain that there is no room for that within the W3C. And that is by W3C rules, not John's rules. Thus making unilateral decisions, while others are working though the disagreement via the 'proper' channels is an affront to me, and causes harm as it brings to question the real 'consensus' requirement of both Working Drafts and other W3C documents. I have no issue with suggesting alternative means of providing what @summary was designed to provide, and of allowing these alternatives to 'duke it out' within the interwebs; in fact I feel that way about many of the open issues - it was a similar suggestion that I long ago made regarding @alt, which now forms the basis of the current spec language regarding text alternatives for images. So I believe I have great flexibility on delivering outcomes, but zero tolerance for stepping outside of W3C protocol and the notion of real fairness and open consensus. > > I'm more interested in whether such a statement is true than who is > making it. > The truthfulness of that statement will likely be a costly truth borne by one, as it will likely take a court challenge to determine the definitive answer. It is my belief however that it is a truthful statement today, however it is an opinion, and not foundation for a W3C Official Document (be that document a Working Draft, Official Guidance, or 2009 Press Release). > > > Here's another compromise proposal: make @summary conformant but > > deprecated (not obsolete), and remove author instruction that tells > > authors not to use @summary as this directly contradicts WCAG 2. > > Thanks for making an alternate proposal. What do you think is the > substantial difference between "deprecated" and "obsolete" status? To > me they seem like pretty much the same thing. It's allowed, but not > recommended. The current W3C definition of deprecated and obsolete can be found at: http://www.w3.org/TR/html4/conform.html#deprecated "Deprecated: A deprecated element or attribute is one that has been outdated by newer constructs. Deprecated elements are defined in the reference manual in appropriate locations, but are clearly marked as deprecated. Deprecated elements may become obsolete in future versions of HTML." "Obsolete - An obsolete element or attribute is one for which there is no guarantee of support by a user agent. Obsolete elements are no longer defined in the specification, but are listed for historical purposes in the changes section of the reference manual." By my reading there are significant differences between either state. If WHAT WG does not make these distinctions then could you kindly point me to the WHAT WG definition of both or either term? (This might be an existing hole in the Draft Specification that perhaps needs to be plugged?) > > This is a good idea. Someone should propose a change to WCAG2 based on > the data collected on summary="". > I am sure that WAI and the PFWG would listen very carefully to anything the HTML WG might offer as a constructive observation and recommendation. I invite you to make such a proposal; WAI welcomes input and comments from all sources and can be reached in a number of ways: http://www.w3.org/WAI/contacts#documents > > I do appreciate it. And I appreciate that you made an alternate > compromise proposal. What I'd like to understand now is why a > "deprecated" summary attribute would meet your requirements, but an > "obsolete" one would not. Is it just the particular word and how > judgmental it sounds? Or do you see some other difference? Hopefully the W3C definitions I quoted make the difference clear. Deprecating @summary makes it suitable for use today, and allows WCAG 2 to remain true to its guidance - deprecation however also signals that @summary's days will likely come to an end, so that if/when WCAG 2 comes up for review the reviewers will be advised that the current guidance needs to be modified. Maciej Stachowiak also wrote: > > My understanding of the W3C Process is that Working Drafts do not > signal that a spec is nearing stability. They merely signal that the > spec is not dead yet. A Last Call Working Draft would be signal that > the spec is nearing stability. That would be the point where I think > open technical issues should block publication. ...and if we did not have the main proponents behind HTML5 actively advocating using HTML5 today, it would be less of an issue. But companies such as Opera are sending speakers out today (and Bruce Lawson is a friend) extolling the virtues of HTML5 and showing that it can be used today; organizations such as Mozilla are showcasing 'tools' such as Bespin that absolutely rely on HTML5 (because it requires <canvas>); and Google is announcing in not-too-subtle ways that the future is HTML 5, and that future is here today [2][3]. Thus the Working Drafts are carrying way more weight and significance than they should, but that is the way it is in part because that is the way you have set it up. For these reasons then, opponents of specific pieces of the emerging Draft must argue louder, and frankly fight harder, to simply ensure that we are not dealt a fait acomplis, which is a very real and legitimate concern. It is the reason why *I* am standing where I am regarding the publishing of a heartbeat doc, because those heartbeat documents are delivering way more in practice than was intended when the requirement for them was developed. JF [1 http://en.wikipedia.org/wiki/Truthiness ] [2 http://radar.oreilly.com/2009/05/google-bets-big-on-html-5.html ] [3 http://www.webmonkey.com/blog/Google_Throws_Its_Weight_Behind_HTML_5 ]
Received on Sunday, 2 August 2009 01:21:26 UTC