Re: Discussion: Accessibility Issues Procedure

Shelley Powers wrote:
> On Sun, Jul 26, 2009 at 6:36 AM, Sam Ruby<rubys@intertwingly.net> wrote:
>> Ian Hickson wrote:
>>> On Sat, 25 Jul 2009, Sam Ruby wrote:
>>>> Let me enumerate a few possible ways forward. [...]
>>>>
>>>> Option #5 is to accept what currently is in Ian's draft.
>>> Option #6 is for people to actually respond to my requests for
>>> explanations of the various proposals that people have made, so that I can
>>> actually understand people's positions. As has been demonstrated multiple
>>> times even with the summary="" attribute, when people make reasoned
>>> arguments and demonstrate why their proposals are a good idea, I change the
>>> spec to follow them.
>> +1
>>
>> - Sam Ruby
>>
>>
> 
> Sam, which is it to be?
> 
> Draft the change and incorporate into the HTML 5 specification? Or
> spend time repeating the same discussions, over and over again? Ian is
> fully aware of the issues, reasons, and so on. If he isn't I suggest
> he spend time searching on @summary in these lists.
> 
> This is the rubber meets the road time. We have an option to meet all
> demands: the document would contain the various ways of incorporating
> table information, per Ian; but it would also remove the summary
> attribute from obsolete status, incorporate it as an example, and also
> add more information (per William) about what the summary is.
> 
> This is a _compromise_.

I don't believe that we have consensus on that compromise.  We can 
assess consensus via a vote or poll.  Concrete spec text, integrated 
into the specific section(s) of the draft is the most productive way to 
achieve that in a way that ensures that there is a common understanding 
of what that approach implies.

> This gives folks _options_ in how to describe tables.
> 
> Most importantly, all of the above combined helps ensure that people
> are aware that they need to provide descriptive information about
> tables for those using screenreaders. And, in the end, that's all that
> matters.
> 
> This does _not_ abrogate additional accessibility input and changes in
> the future. This has to do with @summary attribute, only.
> 
> I have volunteered the time to make the changes to an HTML spec, some
> spec, and do what it takes to incorporate the changes into the main
> document. But I'm not going to spend my time indulging in the same
> useless, circular argument.
> 
> Either/Or. Either we continue these endless discussions, or we do the
> work.  You asked for someone to take this on. I have expressed
> willingness. I'm also willing to step aside if someone else from the
> accessibility community wants to do this work. Or I'll work with
> others, with the understanding that we're making this change in the
> next couple of weeks, so this group can move on. Because we need to
> move on.

I agree that it is rubber meets the road time.

My intent of +1 wasn't to suggest that there be only one option, but 
merely to agree that what Ian described was an option.  It was my intent 
to convey what Ian said in my *first* option, but clearly he said it 
better than I did.

On Thursday's HTML WG call, a reasonable number of PFWG people attended. 
  On Friday morning I posted my opinion that "I don't wish to design and 
build the poll but I hope that my initial draft is enough to get this 
work moving." wasn't enough.  That was after seeing the reaction of 
people like yourself, Ian, Maciej, and Laura.  Since that time I have 
been in contact with a number of PFWG members, via IM and phone.  I 
believe that I have a good working relationship with them, and I do 
believe that they now have a good understanding of how to proceed, and 
that that understanding is basically what I outlined in my 5 (and now 
6ish) options.

The current state in Ian's current draft is that @summary is conformant 
but obsolete.  The proposed wording for a straw poll isn't complete.  I 
fully agree with Maciej's response[1].

Shelley, you've come the closest I have seen to a coherent counter 
proposal[2].  I do mean that as a compliment, and I hope that you take 
it as such.

Meanwhile, let me be quite clear: If you believe that you can work with 
Ian, please do so.  In fact, I will go further and say that that is my 
preference.  For many, that's all they need to do.

However, if you feel that the option of working with Ian has ceased to 
be productive, don't let that stop you.  In fact, I encourage you to 
directly make edits to one or more drafts based on the input you have 
heard and any opinions you might have.  Feel free to use the cvs 
facilities of the W3C.  If you would prefer something closer to the 
source that Ian edits, while I don't have access to the WHATWG SVN, I do 
have a full git clone[3] that you can pull from and merge and establish 
a branch etc.  It is up to date[4].  You can include Manu's work, or 
not, as you see fit.  We can vote on them together or separately, as 
people see fit.

 From observation of you over the past several years, I don't believe 
that any of the above is beyond your abilities.  If you have any 
questions, feel free to contact me either publicly or privately (my 
preference is publicly, as it will benefit all, and limit the times I 
have to repeat myself).  But for those not as familiar with the Unix 
developers toolchain, simply directly make edits to a document (Ian's 
source, or the published w3c doc, I care not), and make available both 
the original that you edited and your updated copy, and I will either 
personally do the diffs and integration and publishing, or will find 
someone who will.

> Shelley

[1] http://lists.w3.org/Archives/Public/public-html/2009Jul/0669.html
[2] http://lists.w3.org/Archives/Public/public-html/2009Jul/0677.html
[3] http://code.intertwingly.net/public/git/webapps/
[4] http://code.intertwingly.net/public/git/?p=webapps;a=summary

Received on Sunday, 26 July 2009 15:53:55 UTC