RE: [DRAFT] Heartbeat poll

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