- From: Sam Ruby <rubys@intertwingly.net>
- Date: Wed, 14 Dec 2011 13:31:27 -0500
- To: david bolter <david.bolter@gmail.com>
- 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
On 12/14/2011 10:10 AM, david bolter wrote: > Hi Sam, all, > > (Is top posting ok?) > > Can someone please provide links to the various and most recent proposals? The following does not have any rationale provided, but you are welcome to comment on it: http://dev.w3.org/html5/2dcontext/ Additionally, we have the following: http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection http://www.w3.org/html/wg/wiki/ChangeProposals/FocusRingTextBaseline > 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. It would be helpful if those voices were to participate here, on public-html. > 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. It would also be helpful to enumerate any strong objections to the completed and incomplete proposals identified at the top of this email. > Cheers, > David - Sam Ruby > On Tue, Dec 13, 2011 at 8:24 AM, Sam Ruby <rubys@intertwingly.net > <mailto:rubys@intertwingly.net>> wrote: > > On 12/13/2011 06:17 AM, Richard Schwerdtfeger wrote: > > Sam Ruby <rubys@intertwingly.net > <mailto:rubys@intertwingly.net>> wrote on 12/09/2011 09:25:14 PM: > > > From: Sam Ruby <rubys@intertwingly.net > <mailto: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 18:32:09 UTC