W3C home > Mailing lists > Public > www-archive@w3.org > July 2009

Re: PROPOSAL: Procedure to Promote Progress With Accessibility Issues in HTML5

From: Shelley Powers <shelleyp@burningbird.net>
Date: Tue, 21 Jul 2009 11:31:43 -0500
Message-ID: <4A65ED6F.5060106@burningbird.net>
To: Sam Ruby <rubys@intertwingly.net>
CC: Steven Faulkner <faulkner.steve@gmail.com>, www-archive <www-archive@w3.org>

>> I am still unsure whether collaboration is actually useful in terms 
>> of the current procedural regime:
>> If i write a spec that only has changes to the alt section i would 
>> think it more likely to gain support, than if it also included RDFa, 
>> thus i am discouraged from collaboration.
>> I consider a much fairer and more manageable way to handle it would 
>> be to allow people to write modified sections or subsection and then 
>> put each section up to a vote if consensus cannot be achieved.
>> if there is not a section or subsection that has a draft alternative 
>> has been produced and there are no formal objections realted to it, 
>> then it can be considered as having consensus and be left in the 
>> draft for last call.
>> example:
>> a vote on 3 choices
>> ians image section
>> steves image section
>> person x's image section
>> which ever gains the most support is the one that goes into the FPWD 
>> for last call.
>> another example:
>> manus RDFa section
>> ian's microdata section
>> both microdate and RDFa
>> which ever gains the most support is the one that goes into the FPWD 
>> for last call.
>> then we could end up with a document that is the product of the W3C 
>> HTML working group.
> If that's how people want to proceed, I'm OK with that, with but one 
> minor reservation... ultimately there will need to to be somebody who 
> is willing and able to do the necessary integration.  I gather that 
> Manu is willing to do that up to a point, but it would not surprise me 
> if he became considerably less enthusiastic about investing the time 
> if (for example) RDFa wasn't included.
> I wouldn't worry too much about it at this point.  If people want a 
> vote, there will be a vote.  Even my opinion doesn't count for all 
> that much: for example, I would prefer a vote on a document that 
> contains tangible spec text for the table element including a summary 
> element, but people who are preparing the text of the vote apparently 
> want something else.  If people agree to what they prepare, we will go 
> with that.

I think you misunderstand what people are willing to propose. For 
instance, I imagine those folk wanting to put a @summary vote out to be 
willing to put out tangible text for that section, but they don't want 
to have to duplicate the entire document just to propose that one 
section. You see? That makes no sense. There's a reason sections have 

As for editing, I don't think there would be that much of a problem 
finding someone willing to integrate the different vote results. But you 
left something out: Ian Hickson is the only "official" editor of the 
only "official" version of HTML 5. (Ignoring the no longer active Apple 

So, how do you get to A from B, Sam? How do you get from our existing 
state today, to one where these supposedly alternative sections are 
voted on, and then there needs to be integration of the voting result 
made by _someone_, when the only person who is _allowed_ editing access 
is Ian Hickson?

It gets fuzzy after that point. Sorry if I'm asking for what's obvious 
to everyone else, but could you give me the precise steps to take, from 
prep of voting text, to vote, to incorporation into existing working 
draft based on your preferred approach (camera ready spec text)?

>> -- 
>> with regards
>> Steve Faulkner
>> Technical Director - TPG Europe
>> Director - Web Accessibility Tools Consortium
>> www.paciellogroup.com <http://www.paciellogroup.com> | www.wat-c.org 
>> <http://www.wat-c.org>
>> Web Accessibility Toolbar - 
>> http://www.paciellogroup.com/resources/wat-ie-about.html
> - Sam Ruby

Received on Tuesday, 21 July 2009 16:32:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:43:34 UTC