W3C home > Mailing lists > Public > public-html@w3.org > December 2011

Re: Request to re-open issue 131

From: david bolter <david.bolter@gmail.com>
Date: Wed, 14 Dec 2011 10:10:09 -0500
Message-ID: <CAEO7jQDhtKoDTyNX0kHKPukbgTn6kZU3X6xT9HPXj33OiJxmsw@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, chuck@jumis.com, Cynthia Shelly <cyns@microsoft.com>, dbolter@mozilla.com, franko@microsoft.com, Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
Hi Sam, all,

(Is top posting ok?)

Can someone please provide links to the various and most recent proposals?

Unfortunately I get confused following the canvas accessibility churn. I
can share that the current plan as I understand it is to make sure the
child dom of canvas is exposed correctly in Firefox, but this hasn't turned
out to be our highest priority accessibility work this quarter. Taking this
one step at a time is roughly the plan and adding canvas accessibility
support specific to text is not something we've committed to or not yet, to
my knowledge (and I don't see how we could make a statement on this).
Personally, I really like to have patches in hand before committing ;)

I think the successes of ARIA (much props to Rich) happened because we were
implementing in parallel.

At Mozilla there are certainly voices for avoiding any kind of
encouragement of canvas-for-text-app usage. That said, in what Rich has
communicated to me, he has seemed to me to be asking for a reasonable bare
minimum, but again, I would like to make sure we share the same links to
what we're discussing.

Cheers,
David

On Tue, Dec 13, 2011 at 8:24 AM, Sam Ruby <rubys@intertwingly.net> wrote:

> On 12/13/2011 06:17 AM, Richard Schwerdtfeger wrote:
>
>> Sam Ruby <rubys@intertwingly.net> wrote on 12/09/2011 09:25:14 PM:
>>
>>  > From: Sam Ruby <rubys@intertwingly.net>
>>  > To: Richard Schwerdtfeger/Austin/IBM@IBMUS**,
>>
>

> > Date: 12/09/2011 09:25 PM
>>  > Subject: Re: Request to re-open issue 131
>>  >
>>  > On 12/09/2011 05:42 PM, Richard Schwerdtfeger wrote:
>>  > > I see Ian replaced the entire Canvas 2D API spec. without a
>> formalproposal:
>>  > >
>>  > > http://dev.w3.org/html5/**2dcontext/<http://dev.w3.org/html5/2dcontext/>
>>  >
>>  > Should a formal proposal not be forthcoming, and should you be able to
>>  > obtain testimonials from at least two major implementors that that they
>>  > would be willing to implement your proposal should it be adopted, then
>>  > you have nothing to worry about. If you need to modify your Change
>>  > Proposal(s) in order to obtain these testimonials, you have the
>>  > opportunity to do so. We've not established a deadline yet for this,
>>  > but the earliest deadline we would impose would be late January by this
>>  > point. It could possibly even be later.
>>  >
>> 1. We are not in Candidate Recommendation phase. No such W3C process
>> requires implementations before CR.
>>
>
> First I will state that I understand the frustration.
>
> At CR we will looking for compatible implementations of the spec.
>
> What we are looking for now is something different than that.
>
> We have statements by individuals purporting to represent implementations
> that they WILL NOT implement the W3C specification. Those statements, if
> true, would represent very strong objections.
>
> To date, those people have declined to provide new information.  They have
> declined to provide a new change proposal.  That's the problem I intend to
> focus on.
>
>
>  2. Microsoft, IBM, and Mozilla were presenting a canvas accessibility
>> workshop for SXSW targeted for early March where we would be doing
>> implementations. By breaking process the HTML working group chairs
>> effectively broke the ability to implement the specification as you
>> removed all the caret and selection processing.
>>
>> We already made a proposal which the chairs voted on and the chairs
>> allowed a proposal that has no implementation to come in and override
>> it. No browser manufacturer has implemented the new focus ring APIs in
>> the edited spec. For example, Webkit does not even have fallback content
>> in it yet so indicating where the focus ring is in fallback content on
>> an accessible is a very long way off right now.
>>
>> 3. Chrome follows the Firefox implementation for accessibility. I know
>> this as I work with both browser manufacturers.
>>
>
> Can we get a simple statement from Mozilla?  All it needs to state is that
> they intend to implement whatever the 2D Canvas API might contain for a
> focus ring API in the W3C spec?  We are not looking for a commitment as to
> timeframes.  We are simply looking for a statement of intent at this point.
>
>
>  So, what the chairs have done is responded by heresy by perhaps one
>> chair from Apple.
>>
>
> I encourage you to read the Discussion Guidlines:
>
> http://www.w3.org/html/wg/**wiki/DiscussionGuidelines<http://www.w3.org/html/wg/wiki/DiscussionGuidelines>
>
> While the remainder of your email was professional, I will state that the
> above sentence crossed the line.
>
>
>  This is why W3C has a process and why companies like IBM participate in
>> standards efforts. The process is designed to take input from all
>> participating members and provides adequate time to allow members to
>> implement the specification. Not only did the chairs break process but
>> they also hindered implementations under way.
>>
>> 4. Caret and selection processing was removed. These were critical
>> features that drive magnifiers for low vision users. There is nothing in
>> Ian's change that supports those use cases which the chairs approved.
>> Now, perhaps Ian preferred a better API but no such replacement came
>> forth in the change. They were simply deleted.
>>
>
> The text that was selected continues in the lasted published WG draft. It
> is true that it no longer exists in Ian's editor's drafts.  I have stated
> that you have an opportunity to produce a "Richard's" editor's draft, and
> have it published alongside Ian's.
>
> Should we get statements from multiple browser vendors of their intent,
> and we continue to NOT get new information and NOT get a new Change
> Proposal, then we will reinstate the prior decision.
>
>
>   > > Could you please clarify how this is consistent with the HTML working
>>  > > groups decision policy or with the process you refer to below?
>>  >
>>  > There exists a document in CVS with Ian's name on it with the following
>>  > text prominently in the frontmatter:
>>  >
>>  > The publication of this document by the W3C as a W3C Working Draft
>>  > does not imply that all of the participants in the W3C HTML working
>>  > group endorse the contents of the specification. Indeed, for any
>>  > section of the specification, one can usually find many members of
>>  > the working group or of the W3C as a whole who object strongly to
>>  > the current text, the existence of the section at all, or the idea
>>  > that the working group should even spend time discussing the
>>  > concept of that section.
>>  >
>>  > If you would like to create a parallel document in CVS with your name
>> on
>>  > it and the same disclaimer, we will help you do that. But I will state
>>  > that there really is no need to do that. Your Change Proposals are
>>  > sufficient.
>>  >
>> If our original change proposals were sufficient and they were indeed
>> voted on then why would the chairs allow an alternative (non-voted on
>> spec.)?
>>
>> The point being that our change proposals for Issue 131 were clearly not
>> sufficient as someone is simply able to overwrite them.
>>
>>
>>  > I already stated why the Chairs elected to take this action. If you
>>  > have a problem with this, I encourage you to take this up with PLH.
>>  > Mike Smith will assist you in this effort should you decide to go this
>>  > route.
>>  >
>>  > Obviously, I would encourage you to focus on obtaining implementer
>>  > testimonials instead of taking that path, but the choice is yours.
>>  >
>> As I stated, we are not in CR. There should be no reason to do this at
>> this time. We were in the process of implementing them and the chairs
>> torpedoed the effort. Enterprise browser manufacturers want to implement
>> a spec. that is approved. The chairs killed that effort.
>>
>
> No spec, at this point, is approved.  I encourage you to read the status
> section of the editor's working draft carefully.
>
>
>   > > I also noticed Ian went into numerous related defects and added
>> requests
>>  > > for use cases, such as:
>> https://www.w3.org/Bugs/**Public/show_bug.cgi?id=13578<https://www.w3.org/Bugs/Public/show_bug.cgi?id=13578>
>>  > >
>>  > > We have on numerous occasions provided information on things like
>>  > > providing the bounds of an object such as Frank Olivier presented at
>>  > > TPAC. Please refer to the use cases minuted at the TPAC discussion.
>>  >
>>  > I'm pleased to see that things are progressing again. As to Ian's
>>  > request: since you state that the data is already publicly available, I
>>  > encourage you to provide pointers to that data.
>>  >
>> You were at the TPAC face to face and in fact sat in on Frank Olivier's
>> presentation. You are welcome to spend your cycles sending Ian a link to
>> the meeting minutes. The chairs created this situation - not the people
>> working on canvas accessibility.
>>
>> Allowing this to happen raises some concerns for me. These are that the
>> W3C's processes for producing specifications appears compromised and
>> that we are entering an anti-competitive state on the Web. One that does
>> not favor people with disabilities.
>>
>> Unfortunately, we will have to present this change on Canvas
>> accessibility at SXSW and CSUN. Where at one time we had hoped to
>> provide positive work on canvas accessibility, now due solely to the
>> chairs response in this matter, we do not.
>>
>> This is a very sad situation.
>>
>
> Again, I understand the frustration.  But if Mozilla is planning on
> sending representatives to SXSW and CSUN and making statements as to what
> Mozilla intends to implement, perhaps those individuals could be encouraged
> to make such a statement on the public_html mailing list?
>
>
>   > In any case, if for any reason these bugs aren't resolved to your
>>  > satisfaction by December 31st 2011[1], you will have the opportunity to
>>  > escalate the bugs and propose your own resolutions in the form of
>>  > concrete Change Proposals.
>>  >
>>  > > I am leaving for vacation in an hour and will be unavailable for
>> mostly
>>  > > through the end of the year. I look forward to your reply.
>>  >
>>  > Unfortunately, I wasn't around to respond within the hour. Hopefully
>>  > you will see this when you return.
>>  >
>>  > > Best Regards,
>>  > > Rich
>>  >
>>  > - Sam Ruby
>>  >
>>  > [1] http://lists.w3.org/Archives/**Public/public-html/2011Jun/**
>> 0315.html<http://lists.w3.org/Archives/Public/public-html/2011Jun/0315.html>
>>
>
> - Sam Ruby
>
>
Received on Wednesday, 14 December 2011 15:10:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:28 UTC