- From: David Bolter <david.bolter@gmail.com>
- Date: Thu, 07 Jan 2010 14:23:55 -0500
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- CC: jcraig@apple.com, Frank Olivier <franko@microsoft.com>, public-canvas-api <public-canvas-api@w3.org>
Hi Rich, I'm encouraging discussion on our Mozilla bug for this, but in the meantime I can say that no show-stoppers jump out at me. Am I correct that we are for now just discussing the feasibility of this approach, and not the merits? I'm not saying this approach isn't the best, but I just want to clarify the current goal here. Aside: has this been mocked up yet? Perhaps with a div container that follows the canvas application, where the div subtree is displaced offscreen (via the -9999, -9999 hackery). It seems to me that we can test a lot of how this would work, without having to put the non-visual DOM underneath the canvas element. I seem to recall someone having an action item on this. cheers, David On 07/01/10 11:56 AM, Richard Schwerdtfeger wrote: > > Hi David, James, Frank, > > The canvas working group has reached consensus that we should provide a > shadow DOM for<canvas> where the canvas UI is bond to accessible objects > in the shadow DOM. Two things we need to agree on is being able to use > standard input controls and contenteditable areas in the shadow DOM as will > already be accessible in the browser. Since these interactive components > are not visible and would be in the keyboard navigation sequence we need to > know if this will be a problem for Firefox, Safari, or IE. Also, > contenteditable provides a caret location, without which we would need to > provide an API for the caret location to support magifiers and screen > readers. We need to address these action items in the next 2 weeks. > > http://www.w3.org/WAI/PF/HTML/track/actions/4 > > http://www.w3.org/WAI/PF/HTML/track/actions/5 > > Rich: > > Rich Schwerdtfeger > Distinguished Engineer, SWG Accessibility Architect/Strategist >
Received on Thursday, 7 January 2010 19:24:28 UTC