RE: My final attempt on explanation (was RE: [DRAFT] Heartbeat poll - update 2)

First,

Thank you Ian for responding. 

Ian Hickson wrote:
> 
> >
> > "What I've argued, from the beginning, is that in the section "12.1
> > Obsolete" content creators are told specifically *NOT* to use
> @summary.
> > This directly contradicts WCAG 2 guidance in this matter."
> 
> Contradiction other W3C documents isn't a problem. New documents
> contradict older documents as the cutting edge moves along and new
> information comes to light. That's how progress is made.
> 

Here we must agree to disagree.  The engineer in you might not see this as
a problem, the accessibility advocate in me certainly does.  You are
entitled to try and make changes to accessibility guidance, but the way in
which you are attempting to do so today is not the right way.  Your
process for 'progress' is the Wild West way, whilst I and others prefer
the UN way (which is also the W3C way - consensus, diplomacy and
compromise). I have repeatedly asked that you work within the system, not
external to it.

> 
> > About W3C Process
> 
> I didn't want to be the one to have to explain this to you, but nobody
> else is doing so, so here goes: The W3C process doesn't actually require
> that working groups agree, or not contradict each other.

Please support that comment with verifiable proof. I have previously
provided URLs to substantiate my claims, I would expect no less from you.

> The WAI's mission is not binding on other working groups.

Please support that comment with verifiable proof.

> The HTMLWG charter actually says
> that I am expected to write proposals and put them forward in drafts
> exactly as I have been doing.

<q>
Scope:

This group will maintain and produce incremental revisions to the HTML
specification, which includes the series of specifications previously
published as XHTML version 1. Both XML and 'classic HTML' syntaxes will be
produced.

The Group will define conformance and parsing requirements for 'classic
HTML', taking into account legacy implementations; the Group will not
assume that an SGML parser is used for 'classic HTML'.

The Group will monitor implementation of and conformance to the HTML
specification, construct test suites, and from them produce
interoperability reports.

The Group may hold Workshops, Interoperability Meetings, and other events
as required to fulfill its mission.
</q>
[source: http://www.w3.org/2007/03/HTML-WG-charter.html ]

Where in this Scope definition does it say that the HTML WG is charged,
chartered or even asked to provide accessibility guidance?  Maybe I missed
something, but I don't see that request or mandate listed in the HTML WG
Charter anywhere.  Instead, what I see is:

"The HTML Working Group will *cooperate* (emphasis mine) with the Web
Accessibility Initiative to ensure that the deliverables will satisfy
accessibility requirements. Coordination with WAI will be primarily
conducted through the Protocol and Formats Working Group, but direct
coordination with other WAI groups, such as Web Content Accessibility
Guidelines Working Group and User Agent Accessibility Guidelines Working
Group, will also be done when appropriate."

How does publicly disagreeing with the WAI constitute "cooperation"
exactly?  Where is the evidence of "direct coordination with other WAI
groups, such as Web Content Accessibility Guidelines Working Group"?  Was
the text: 

  "Authors should not specify the summary attribute on table elements."

even discussed with any of the WAI working groups before it was added to
your spec?  Can you show me evidence of such?

Putting aside your Editorial opinions, yes, you have delivered on all
other accounts.  I maintain that by imposing your opinion as fact here in
the specification, you have stepped outside of your charge.  Clearly you
disagree, but we are free to disagree. 


> > So last Friday, I set into motion an illustration of why the WHAT WG
> > process is flawed - using WHAT WG rules.  As an alternative Editor, I
> > invoked 'benevolent dictator' status and made a minor change to an
> > existing document that is clearly licensed to allow me to do so. I
then
> > submitted that alternative Draft to the Working Group Chairs for
> > consideration as the next Working Draft.
> 
> As far as I can tell, that was a perfectly reasonable thing to do. I
> certainly support your ability to write such drafts and publish them. To
> be honest I don't understand why your draft hasn't been published.

I have also repeatedly said that I don't think forking or branching the
specification is a positive move.  However because you seem intent on not
modifying the 'guidance' portion of the spec (under 12.1 Obsolete) that
contradicts WCAG 2, I did make that change as an alternative Editor and
released the fork for Working Group consideration.  You have the power to
eliminate the fork by removing one line of text: will you be honest enough
to admit that the text is currently problematic and the source of
disharmony?

> 
> This data boils down to "The WCAG2 documents say so", right? As
mentioned
> above, I don't consider contradicting WCAG2 to be a problem either
> technically, socially, or by W3C process.

And again, we disagree, as we both have a right to do.  The question then
becomes, to you disagree so vehemently that you would rather see a fork in
the spec then give in to the possibility that you *might* be wrong?
Because in many ways this is turning into a test of wills - and Ian,
frankly, I've come this far in "calling the bluff" that I have nothing to
lose by sticking to my point.  (And before anyone point and say that this
is just a game for me, no, this is not a game.  This is an issue of not
letting one person make a decision when the *process* for making that
decision is on-going.  This isn't Judge Judy.) 
[ http://en.wikipedia.org/wiki/Judge_Judy#Criticisms ]


> That's how we make progress,

Within the W3C, progress is made by reaching consensus.  There is no
consensus surrounding @summary, and there is no consensus surrounding your
current advisory text that tells authors to not use @summary.  Progress
through consensus is made when we find a meeting point that all can agree
to.

I have offered numerous scenarios that are 'middle-ground' proposals
between what you believe to be right, and what I believe to be right; I
have also stated that if we could find one of those positions that worked
for you, then I would no longer have an issue.  I have shown a willingness
to bend, you have remained rigid.  Remaining rigid is not how consensus is
built.


> which I'm sure you'll agree is desperately needed if we're to make the
> Web more accessible -- it's not like it's a paragon of accessibility
today.

Agreed.  The WAI just spent nearly a decade trying to come up with good
guidance for content authors to ensure accessible content.  Did you
participate in that effort?  When they were writing
http://www.w3.org/WAI/WCAG20/quickref/#qr-content-structure-separation-pro
grammatic and http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H73 did
you speak up then with your concerns about @summary?  The W3C process
allows for, even insists, that these documents go for peer review - did
you participate?  If not, why not?

You now claim you have data that shows that *to date* (you cannot of
course foresee the future) @summary has been poorly used, and bandy about
loaded terms such as "harm accessibility" (again, an opinion); however
have you approached the WAI with that data and asked that they revisit
their guidance as you too desire a more accessible Web?  As far as I can
tell, you have not.  Instead you have used your position as editor to
advance what you believe to be the 'better' solution, but that 'better'
solution has as many detractors as supporters, data not-withstanding.

> 
> Regarding the WHATWG, I don't think the WHATWG is relevant to the
> internal
> operations of the W3C HTML WG, and I don't think that any WHATWG rules
> are
> affecting the HTML WG. The way that I am editing the spec is within the
> expectations set out by our charter, as far as I can tell.

...and I, and many others, have repeatedly suggested to you that you are
missing an important part: consensus.  You do not get final say - the end.
@summary remains open, and as such the Draft needs to reflect that without
the encumbrance of your authoring guidance.  Once the @summary issues is
resolved, *THEN* the status (complete with or without authoring guidance)
can be added to the spec.

Or... 

We can have two nearly identical specs and we turn to the membership at
large to decide: in either way the outcome will be outside of your
control, as currently you do not seem intent in showing flexibility, but
rather you prefer to stick to your position citing "data". (To which I
will stick to my position and cite "process")


JF

Received on Tuesday, 4 August 2009 00:59:12 UTC