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

Re: Agenda: HTML 5 Canvas Accessibility Meeting February 22, 2010 (resending)

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Mon, 22 Feb 2010 12:32:57 -0600
To: David Singer <singer@apple.com>
Cc: Charles McCathieNevile <chaals@opera.com>, cooper@w3.org, cyns@exchange.microsoft.com, David Bolter <david.bolter@gmail.com>, Steven Faulkner <faulkner.steve@gmail.com>, Frank Olivier <franko@microsoft.com>, janina@rednote.net, James Craig <jcraig@apple.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-canvas-api-request@w3.org, surkov.alexander@gmail.com
Message-ID: <OF9C9C2D29.900EA030-ON862576D2.006377F2-862576D2.0065E519@us.ibm.com>

Hi David,

It can't always be true. The reason is that if <canvas> is the actual
rendering then we cannot guarantee that the <canvas> sub-tree (fallback or
otherwise) is ever an accessibility tree representation of what is drawn on
the <canvas>. If it is not, and it is simply fallback content for browsers
that do not support canvas, the content is not an accessibility
representation for what is drawn on <canvas> and asking:

   asking a test tool to test it for accessibility would have no relevance
   to the UI being rendered. This would be the case today.
   asking the browser to map the sub-tree to the accessibility API would be
   inaccurate as it would not correctly represent the UI rendering

To illustrate this, imagine using Bespin where the fallback sub-tree is an
Iframe with an entirely different editor, say one that looks exactly like
Smultron, emacs or Visual Slick Edit but rendered in HTML. The controls
would be different, etc. Keyboard navigation alone would not follow what is
being drawn on the canvas.

It could also be the case that the sub-tree is meant for a user selectable
alternative rendering in the web application. In which case it does not
have a correlation to the visual rendering and should not be mapped or
tested. If however the user selected the alternative rendering the canvas
could be hidden and the alternative content would be rendered and in
neither case should adom be set to true.

If the flag were indeed true by default then that would restrict the author
as to the intent of the sub-tree content which is inconsistent with how it
is being used today. This would result in an accessibility API mapping and
an accessibility test scenario that is inconsistent with what is being
rendered on the visual canvas.

Consequently, having adom set to false by default would ensure that the
author establish the intent of the canvas sub-tree for accessibility test
tools and ATs at the time it is rendered.

Does that help?

Rich

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist


                                                                           
             David Singer                                                  
             <singer@apple.com                                             
             >                                                          To 
                                       Richard                             
             02/22/2010 10:53          Schwerdtfeger/Austin/IBM@IBMUS      
             AM                                                         cc 
                                       James Craig <jcraig@apple.com>,     
                                       Charles McCathieNevile              
                                       <chaals@opera.com>, cooper@w3.org,  
                                       cyns@exchange.microsoft.com, David  
                                       Bolter <david.bolter@gmail.com>,    
                                       Steven Faulkner                     
                                       <faulkner.steve@gmail.com>, Frank   
                                       Olivier <franko@microsoft.com>,     
                                       janina@rednote.net,                 
                                       "public-canvas-api@w3.org"          
                                       <public-canvas-api@w3.org>,         
                                       public-canvas-api-request@w3.org,   
                                       surkov.alexander@gmail.com          
                                                                   Subject 
                                       Re: Agenda: HTML 5 Canvas           
                                       Accessibility Meeting February 22,  
                                       2010 (resending)                    
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Richard

I think you may be misunderstanding the position.  I agree, today, the
fallback content is discarded by browsers that understand canvas.

We discussed the flag to indicate whether the fallback content should be
used as the (initial) accessibility content, and we also discussed what the
default for the flag should be.  Someone suggested perhaps it should be
'true' by default (unlike today, where it is effectively false).

Now one asks:  is it ever worth setting it to 'false'?  In some cases, it
can save some work on the part of a script;  consider, for example, the
case where the fallback content merely says "get a better browser", but the
accessibility content is a more complex structure that gives (for example)
alternative input method support.  In this case, building the accessibility
DOM tree means you have to tear down that "get a better browser" sub-tree,
but that is easy.

So, if we make the flag true by default, is it needed at all?  Can it be
always true?

On Feb 21, 2010, at 11:14 , Richard Schwerdtfeger wrote:



      HTML <canvas> content should be accessible too. However, I can think
      of none on the web that are today. Your statement of "partially
      inaccessible" makes no sense either technically or logically based on
      what has been implemented for <canvas> to date.

      The purpose of the adom attribute is not an accessibility compliance
      statement "flag." It is an indication to the browser to map what is
      in the subtree to the accessibility infrastructure and to include it
      in the keyboard navigation tree. The subtree, today, is not designed
      to do that. It is basically ignored a browser unless it does not
      support canvas. Setting the flag is not a guarantee that the author
      has done a good job any more than anything else that is out there
      today. That is what accessibility test tools are for.

      The reality is that you should not map the subtree DOM to the
      accessibility API and include it in the navigation order, by default,
      because neither the AT, an accessibility test tool, nor the user have
      any way of knowing the purpose of that content. As for Ian's content
      about the content being non-conforming there is no restrictions on
      what the fallback content is today. It can be anything. Cynthia made
      a very important point, at one of the previous meetings, in that an
      accessibility test tool need to know the content in the sub-tree is
      directly related to the visual rendering to test it. That cannot be
      known unless the author indicates it is.

      There are authors that do not care about meeting accessibility
      criteria and our making a blind assumption that the author should
      care to do so would be irresponsible on our part. Without the
      attribute you would have to REQUIRE that the author make the
      structure and accessibility properties exactly match what you are
      rendering on the canvas in all instances. That is an unrealistic
      expectation of authors and creates an unmanageable situation for
      accessibility test tools. We would also create a situation where two
      people sitting down with a web page application (one sighted and one
      not) will try to operate a web page application and the solution the
      blind user has access to will have absolutely no correlation to the
      one being rendered on canvas keyboard-wise, semantically, etc. It may
      be an entirely different collection of components, which the neither
      user cansee and behaves nothing like the visual rendering.

      I am sorry James, but the argument you present holds no water to me
      and I see no way of us ever reaching consensus on it.

      Rich


      Rich Schwerdtfeger
      Distinguished Engineer, SWG Accessibility Architect/Strategist

      <27158101.gif>James Craig ---02/19/2010 08:17:59 PM---I discussed
      agenda item #2 (@adom) today with Maciej and David, and I've come to
      agree with Ian's original argument that canvas
                                                                           
             James Craig <                                                 
             jcraig@apple.com>                                             
             Sent by:                                                      
             public-canvas-api-reques <27027431.gif>                       
             t@w3.org                                                   To 
                                                    <27027431.gif>         
                                                    Richard                
             02/19/2010 08:17 PM                    Schwerdtfeger/Austin/I 
                                                    BM@IBMUS               
                                      <27027431.gif>                       
                                                                        cc 
                                                    <27027431.gif>         
                                                    David Bolter <         
                                                    david.bolter@gmail.com 
                                                    >, cooper@w3.org,      
                                                    janina@rednote.net,    
                                                    Charles McCathieNevile 
                                                    <?chaals@opera.com>,   
                                                    cyns@exchange.microsof 
                                                    t.com, Steven Faulkner 
                                                    <                      
                                                    faulkner.steve@gmail.c 
                                                    om>, Frank Olivier <?  
                                                    franko@microsoft.com>, 
                                                    "?                     
                                                    public-canvas-api@w3.o 
                                                    rg" <                  
                                                    public-canvas-api@w3.o 
                                                    rg>,                   
                                                    surkov.alexander@gmail 
                                                    .com                   
                                      <27027431.gif>                       
                                                                   Subject 
                                                    <27027431.gif>         
                                                    Re: Agenda: HTML 5     
                                                    Canvas Accessibility   
                                                    Meeting February 22,   
                                                    2010                   
                                                                           
                                                                           
                                      <27027431.gif>                       
                                                    <27027431.gif>         
                                                                           
                                                                           


      I discussed agenda item #2 (@adom) today with Maciej and David, and
      I've come to agree with Ian's original argument that canvas contents
      should just be accessible by default. Though the idea of using an
      attribute was slightly more palatable than an extra element, adding a
      flag of any kind doesn't provide much benefit in the best case
      scenario. In the worst case scenario, it would render partially
      accessible content completely inaccessible.

      James


      On Feb 19, 2010, at 5:23 PM, Richard Schwerdtfeger wrote:


                              Monday, 2010-2-15
                              Time: 3:00pm-4:00pm Boston local
                              Name: WAI_PFWG(CANVAS)
                              Code: 92473 ("WAIPF")
                              One time

                              irc channel= #html-a11y

                              Agenda:

                              1. Identify Scribe
                              2. Final Review for spec. ready adom text for
                              Issue 74
                              http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0178.html

                              3. Progress on caret tracking:
                              http://www.w3.org/WAI/PF/HTML/track/actions/19
                               - Steve Faukner


                              Rich Schwerdtfeger
                              Distinguished Engineer, SWG Accessibility
                              Architect/Strategist

David Singer
Multimedia and Software Standards, Apple Inc.





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

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

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

Received on Monday, 22 February 2010 18:33:45 UTC

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