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: Thu, 7 Jan 2010 13:18:51 -0700
To: David Bolter <dbolter@mozilla.com>
Cc: Frank Olivier <franko@microsoft.com>, jcraig@apple.com, public-canvas-api <public-canvas-api@w3.org>
Message-ID: <OF433E203B.9E27DCD4-ON862576A4.006EB7E0-862576A4.006F96D4@us.ibm.com>

Hi David,

Yes, this is to discuss the feasibility. Although if you have other options
to doing this we are open to hearing them. Ideally, it would be good to
support an accessibility API but the cross-platform consensus process to
achieve this cannot be contained in HTML 5. We will need to address the
issue of driving a magnifier to following the caret and selected text. ...
one thing at a time. :-)

Regarding examples:
James Craig has an updated example with this working. James if you could
post it that would be great.

Here is a basic example that I worked on with Frank that does not make use
of input controls or contenteditable areas:


(See attached file: canvas-acc.html)

Rich

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist


                                                                           
             David Bolter                                                  
             <dbolter@mozilla.                                             
             com>                                                       To 
                                       Richard                             
             01/07/2010 01:22          Schwerdtfeger/Austin/IBM@IBMUS      
             PM                                                         cc 
                                       jcraig@apple.com, Frank Olivier     
                                       <franko@microsoft.com>,             
                                       public-canvas-api                   
                                       <public-canvas-api@w3.org>          
                                                                   Subject 
                                       Re: Canvas shadow DOM question for  
                                       interactive HTML5 elements          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




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
>








graycol.gif
(image/gif attachment: graycol.gif)

pic07892.gif
(image/gif attachment: pic07892.gif)

ecblank.gif
(image/gif attachment: ecblank.gif)

Received on Thursday, 7 January 2010 20:19:45 UTC

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