W3C home > Mailing lists > Public > public-canvas-api@w3.org > October to December 2009

Re: Fw: canvas accessibility progress

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Tue, 3 Nov 2009 08:37:45 -0600
To: Alexander Surkov <surkov.alexander@gmail.com>
Cc: "public-canvas-api@w3.org" <public-canvas-api@w3.org>, Sam Ruby <rubys@us.ibm.com>, janina@rednote.net
Message-ID: <OFD5D03C97.FA41ED7F-ON86257663.004EE8CD-86257663.00505C43@us.ibm.com>

Hi Alex,

Sure, you can site me. Or you can point me to the bugzilla defect and let
me comment. Whichever works.

In the default view the canvas view should be rendered with the
accessibility tree exposed to the AT. In this case we have
aria-activedescendant operable on the canvas element to allow the script
writer to control focus within canvas. I can see where tab navigation could
be an issue for canvas. One suggestion would be to allow for the user to
navigate in and out of the shadow DOM with the keyboard much the same way
we do plug-ins for Java or Flash. This way we don't disrupt the normal tab
cycle. Once "in the shadow DOM" tabbing is confined to within the shadow
DOM. I need to look back at the use cases on canvas accessibility wiki.

I like your idea of binding switching views through accesible actions. That
would be slick. If we do that we should allow the optional view include an
optional description via say the title attribute. ... just a suggestion or
an aria-describedby property to support the accessibility API.

Absolutely we can open the conversation up. I cc'd the public canvas list
serve on the W3C, Janina, and Sam Ruby. Feel free to include whoever you


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

             Alexander Surkov                                              
             @gmail.com>                                                To 
             11/02/2009 09:47          Schwerdtfeger/Austin/IBM@IBMUS      
             PM                                                         cc 
                                       Re: Fw: canvas accessibility        

Hi, Rich.

Can I cite you on mozilla's bugzilla if necessary?

I think tab navigation in shadow tree can make hear attack for any sighted
user, for example developers who uses tools enabling accessibility (in
instance, Mozilla DOM Inspector used by non a11y developers which has
abilities to inspect a11y tree). Also I'm sure Firefox users could find
easy implicit way to enable accessibility (for example, they can install
firefox extension which uses accessibility for its needs) and users might
not know about this. So users can enable accessibility not on their demand
and they got broken tab navigation from their point of view. Therefore I
think tab navigation inside of shadow tree is not only hard-to-implement
thing, it's the thing which can confuse sighted users. Therefore
aria-activedescedant approach is nicer from this point of view. However it
makes impossible normal life of AT users in the case when canvas shadow
tree would have tab navigable controls. The best approach I can think of is
screen readers should be changed to support this. For example, if we'll
change IA2 to provide methods to get next/previous accessibles in tab
navigation order. Dunno.

But I like your idea to switch canvas view. And as you noticed we don't
required to force web page authors to implement buttons allowing to change
the view. We could easy to expose accessible actions so that AT users could
change the view when they want.

However you consider view idea within an ability to expose shadow tree to
AT. And I have more questions than answers how to implement shadow
accessible tree (for example, tab navigation problem). Nevertheless could
we change this idea to get rid this? For example, if there is no @view
attribute then canvas bitmap is rendered, if @view="default" then shadow
tree is rendered for all users and etc. From implementation point of
view we shouldn't dig into trick mozilla layout implementation and don't
need to rape mozilla layout guys to make shadow tree accessible. As well it
will hurt neither sighted users nor blind users by tab navigation problems.
What do you think?

Can we cc more people to our discussion?

Thank you.

On Fri, Oct 30, 2009 at 10:28 PM, Richard Schwerdtfeger <schwer@us.ibm.com>
  Hi Alex,

  We are going to need 3. We will need to have aria-activedescendant work
  too. Apple expressed an interest to have tabindex work as well in the
  shadow DOM but that creates the focus rendering issue. Will the Mozilla
  team have a heart attack over that?

  So, here are my thoughts for the Mozilla team skeptics: Canvas is a brand
  new paradigm shift for the Web. Canvas needs to be considered the view
  and a rendering representative of the model that backs it. SVG is going
  to have similar issues going forward. We need to do the prototyping to
  vet out the issues before we impact the HTML or Canvas specification. So,
  we need to work together. What I would do for now is simply disable all
  rendering of child content now for option 3 - including keyboard focus
  for the child content. It should be up to canvas to do that. We should
  also consider doing the following long term:

  <canvas view="">
  <div> ...

  where the value of view is:

  default: use the default canvas view and depend on child content for
  accessibility (what we are doing now)
  textmodality: This is a text alternative rendering for a complex
  visualization: Example use case: grid alternative to a 2D graph. driving
  direction alternative to a map.; a closed caption version of a video
  audiomodality: audio equivalent to visual view.

  An AT or script author could change the property could then switch the

  Something like:

  <canvas view="">
  <defalult> (this is un-rendered)
  <div role="document">
  <div role="grid">
  <div role="row">
  <div role="gridcell" tabindex="0">

  Rich Schwerdtfeger
  Distinguished Engineer, SWG Accessibility Architect/Strategist

  Inactive hide details for Alexander Surkov ---10/30/2009 01:21:54
  AM---Hi, Rich. I got some discussion with Mozilla layout folkAlexander
  Surkov ---10/30/2009 01:21:54 AM---Hi, Rich. I got some discussion with
  Mozilla layout folk (
                         Alexander Surkov                                  
                         10/30/2009 01:20               Richard            
                         AM                             Schwerdtfeger/Aust 
                                                        Re: Fw: canvas     

  Hi, Rich.

  I got some discussion with Mozilla layout folk (

  There are few options we can follow to make canvas accessible:
  1) Render canvas child content within canvas bitmap
  2) Render canvas child content only
  3) Render canvas bitmap only and expose canvas child content to AT.

  1) and 2) options might be controlled by special preference settings in
  Firefox if we'll find them appropriate. In my opinion 3d option should be
  the best because users don't need to play with preferences and sighted
  users don't see canvas child content when proposed preference is switched
  on. However it's a bit longer way and harder to implement. On the another
  hand if I get right our layout gurus are a bit sceptic to spend their
  time to discuss implementation details for the things wich aren't in the
  spec and especially if we were asked to have a pilot version only. So for
  the first approaching I could write small extension that will insert
  canvas child content into the DOM and therefore it will become
  accessible. One things that bothers me it's completely different from 3d
  option and therefore, for example, it can't demonstrate focus management
  via aria-activedescedant.

  What do you think?

  Thank you.

  On Thu, Oct 29, 2009 at 10:42 PM, Richard Schwerdtfeger <
  schwer@us.ibm.com> wrote:
        Hi Alex,

        As a general strategy, browsers like FF will need to consider
        having the accessibility object model a reflection of what is not
        visible for technologies like SVG and canvas. When I brought ARIA
        to W3C the intent was to leverage the existing visible DOM as it is
        very much like today's GUIs. This will support HTML markup for a
        very long time. Yet, SVG and canvas are different animals. Here,
        your model is more like a collection of drawing primitives. Our
        solution needs to be one where we either:

        1. provides an accessibility tree (hidden as you point out) bound
        loosely to what is being drawn and makes use of ARIA 1.0
        2. provides for an accessibility API bound to these objects (longer
        term). Will require an ARIA 2.0 approach allowing for customization
        3. allows for equivalent alternative content

        So, for now we need to address 1 which you are doing. This should
        be adequate to support Bespin but not say 3D graphics.

        I look forward to your canvas child content approach. This is in
        line with what we have been discussing.


        Rich Schwerdtfeger
        Distinguished Engineer, SWG Accessibility Architect/Strategist

        Inactive hide details for Alexander Surkov ---10/29/2009 04:57:36
        AM---Hi, Rich. Thank you for an example.Alexander Surkov
        ---10/29/2009 04:57:36 AM---Hi, Rich. Thank you for an example.

  Alexander Surkov <?surkov.alexander@gmail.com>                           
  10/29/2009 04:57 AM                                                      
                                                          Re: Fw: canvas   

        Hi, Rich.

        Thank you for an example.

        Since accessibility in Firefox depend a lot on layout, for example,
        we create HTML accessibles based on layout rather than DOM then we
        could fix the code to create accessible objects based on DOM if the
        HTML content is inside of canvas. This a hack but it shouldn't be
        hard to implement. However since DOM nodes inside of canvas aren't
        rendered therefore created accessible will have invisible state
        which will prevent AT to work with them I think. Though I guess it
        could be fixed as well by more or less hack way.

        On the another hand I think theoretically there is another option
        which is to render hidden canvas child content in memory. However I
        don't have any clue how hard to implement this. Though obviously it
        should be more correct way because we could expose styling and etc
        to AT in this case.

        However if we will think about things like Bespin where editor is
        required then I'm not sure either way could be powerful. For
        example, editor's clipboard operations aren't work until editor is
        focused. I would guess we can't set focus in either approach. I
        think it should be more powerful way is to provide JS interfaces to
        allow accessible object creation in JS. I agree DOM-based approach
        should fit greatly for simple examples like your one. But it seems
        to me it's needed something more powerful in the case of
        Bespin-like stuffs.

        Please give me a couple of days to clarify an idea with canvas
        child content rendering in memory.

        Thank you.

        On Wed, Oct 28, 2009 at 11:29 PM, Richard Schwerdtfeger <
        schwer@us.ibm.com> wrote:

                    This is an fyi. Attached is a sample for you to check.


                    Rich Schwerdtfeger
                    Distinguished Engineer, SWG Accessibility
                    ----- Forwarded by Richard Schwerdtfeger/Austin/IBM on
                    10/28/2009 10:28 AM -----
                                              r/Aust                    To 
                                                            Frank Olivier  
                                              10/28/        franko@microso 
                                              2009          ft.com>, "?    
                                              10:10         public-canvas- 
                                              AM            api@w3.org" <  
                                                            .net, Laura    
                                                            Carlson <      

                    Frank sent me a sample of canvas with a shadow DOM
                    which I added aria live region support for. The shadow
                    DOM is exposed in the actual DOM but a screen reader
                    cannot speak it becuase it is not exposed to the
                    accessibility API. This is due to the fact that it is

                    So, the next step is to expose the shadow DOM. Alex
                    Surkov is giving me a time for when he can have a test
                    patch that:

                    - exposes the shadow DOM to the accessibility API
                    - supports aria-activedescendant on canvas. This will
                    allow the canvas author to triger focus change events
                    in the shadow DOM by simply modifying the active id in
                    the canvas element. This is low impact on the browser
                    rendering engine because they don't have to draw

                    Frank, as soon as I get a patch or test build I will
                    tell you how to get it. Attached is my updated sample.

                    (See attached file: canvas-acc.html)


                    Rich Schwerdtfeger
                    Distinguished Engineer, SWG Accessibility

(image/gif attachment: graycol.gif)

(image/gif attachment: pic27773.gif)

(image/gif attachment: ecblank.gif)

Received on Tuesday, 3 November 2009 14:38:48 UTC

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