W3C home > Mailing lists > Public > public-canvas-api@w3.org > January to March 2010

RE: Canvas shadow DOM question for interactive HTML5 elements

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Wed, 20 Jan 2010 15:21:40 -0600
To: Frank Olivier <franko@microsoft.com>
Cc: public-canvas-api@w3.org
Message-ID: <OF2B892DD1.255AD128-ON862576B1.00586E19-862576B1.00755784@us.ibm.com>
Frank, 

Thank you. Now we just need to deal with alternative content driven by CSS 
media queries. The shadow DOM will take us a long way but there will be 
times when alternative content is needed. 

We should try to synchronize the media query properties used by video, 
audio, a new visual (alternative for canvas) with IMS Global Learning 
Consortium access for all resource meta data and user preferences.

Rich

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist



Frank Olivier <franko@microsoft.com> 
01/19/2010 02:34 PM

To
Richard Schwerdtfeger/Austin/IBM@IBMUS
cc

Subject
RE: Canvas shadow DOM question for interactive HTML5 elements






After investigating this with my team – yes, this approach could work in 
the ie architecture; we can ‘hide’ the actual control object while the 
user interact with another representation (of said control)
 
This is actually somewhat similar to what we’re doing today in IE9 with 
our D2D (Hardware-accelerated) design.

Thanks
Frank
 
From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] 
Sent: Thursday, January 07, 2010 8:56 AM
To: David Bolter; jcraig@apple.com; Frank Olivier
Cc: public-canvas-api
Subject: Canvas shadow DOM question for interactive HTML5 elements
 
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 Wednesday, 20 January 2010 21:22:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:49 UTC