Re: Canvas accessibility draft proposal

That is correct. I don't want to spend a lot of cycles writing spec ready
content if we are not going to be on the same page. There are only so many
hours in the day. I would have spent hours writing spec. ready code only to
have someone say "go look at David Singer's proposal." The proposal was
meant for discussion.

I also do not think only delivering a shadow DOM for something as
complicated as canvas is adequate.  We need to be able to provide
alternative content for things like maps and bar charts. It is a tremendous
waste of a developers time to try and make a map accessible to a blind
user. While I understand you saw a tactile map example that is not
practical for a glass screen. We need to provide for both a shadow DOM and
equivalent alternatives. At IBM Cognos makes extensive use of 2D charts
where they provide an accessible alternative. The user decides which view
they want.

Now you mentioned we had different views of a shadow DOM. Please elaborate
so that we can all get on the same page. The response is not constructive
to say "we have different views of what a shadow DOM is." The comment on
the focus model is constructive so I will look at improving that.

The Access For All V1 also became an ISO standard. I will look at Singer's
proposal. I need to find it again.

Rich



Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist.


                                                                           
             James Craig                                                   
             <jcraig@apple.com                                             
             >                                                          To 
                                       Richard                             
             11/17/2009 01:33          Schwerdtfeger/Austin/IBM@IBMUS      
             PM                                                         cc 
                                       public-canvas-api@w3.org, David     
                                       Bolter <david.bolter@gmail.com>,    
                                       Steven Faulkner                     
                                       <faulkner.steve@gmail.com>,         
                                       Alexander Surkov                    
                                       <surkov.alexander@gmail.com>        
                                                                   Subject 
                                       Re: Canvas accessibility draft      
                                       proposal                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Instead of coming up with a third method for alternate media selection, you
should try rolling this in line with David Singer's accessible media query
proposal, which has initial acceptance from the CSS working group, or
Sylvia Pfeiffer's itext proposal, which is being discussed by the HTML 5
working group.

Portions of this proposal are vague or subjective, and most of the language
is not spec ready. For example, anytime you use RFC-2119 keywords (MAY,
SHOULD, MUST, SHOULD NOT, MUST NOT, etc.) you should always phrase the
requirements in active voice with a clear subject and action. In other
words, don't just specify WHAT is required, but also WHO is required to do
it, and WHEN. Much of the language below is vague on all three points.

I think all of us have slightly different ideas of what we mean by the
"shadow DOM." Instead of concentrating your work on a spec proposal that
includes media selection and details about bounding boxes (which may not
even be necessary), try to explain in plain language your understanding of
how the "shadow DOM" focus model is supposed to work. Before anything is
put to spec, we should all have the same basic understanding of how that's
intended to work. It's clear to me that no one agrees on that yet so, while
I appreciate and admire your eagerness to get something in writing, I feel
the result is premature.



On Nov 17, 2009, at 8:30 AM, Richard Schwerdtfeger wrote:



      So, I am listening to all this and would like to make a draft
      proposal for the HTML working group meeting this week (Paul Cotton
      made a request):

      1. Modify the canvas element to support aria-activedescendant where
      the id refers to a valid id in a shadow DOM.
      2. The canvas element shall support zero or more child access
      elements representative of alternative views. The access element
      shall have a mode attribute. Whose values are based on a subset of
      the IMS Global Consortium Access for All Meta Data V3 default. The
      default mode would be representative of the shadow DOM. In many
      instances a more usable solution may require an alternative.
      3. The mode content attribute values for access would be:
      - default - representing the shadow DOM for the complex visual
      rendering of <canvas>
      - textual - Here we could place a long description or an alternative
      accessible UI renderable using HTML 5 standard markup - including
      ARIA.
      - auditory - an audio alternative. Some users may prefer this
      - visual - This is really an alternative for audio but it would
      address things like signLanguage

      Note: access for all also supports "tactile" and "olfactory". I would
      recommend ignoring those for now. These could added in future
      releases of HTML.

      4. The access element would include a type attribute for which we
      should take a subset of the list (from AccessForAll):
      audioDescription, caption, e-book, signLanguage, highContrast,
      transcript, alternativeText, longDescription, haptic}

      The e-book may be rendered with a plug-in. We can choose a subset of
      these if necessary. At this point this is for discussion purposes.

      5. View Selection should be based on a user preference in the browser
      based on the mode and type preference supported in HTML 5. If nothing
      is set, the shadow DOM is used for the accessibility mapping when
      provided. The user agent should select the first view that fits the
      user's request. Platform accessibility API may also be used to
      configure the view selection. Note: is no alternative view is
      provided to meet the preferences the view reverts back to the canvas
      + shadow DOM view. The shadow DOM is also optional.

      6. The canvas tag shall include a script method to set the bounding
      rectangle for a given valid id in the shadow DOM. This would allow
      the browser to provide the bounding rectangle for the id in the
      shadow DOM when it receives focus. The rectangle should be relative
      to the location of the canvas element and would be converted to
      screen coordinates in the accessibility API and would allow the
      canvas to move without changing the location of the shadow DOM
      element. This will allow screen magnifiers to determine the visible
      focus. (Ideally it would be nice to also do this via XPath statements
      vs. id)
      7. All allowable HTML elements in the shadow DOM shall support the
      tabindex content attribute and ARIA attributes.
      8. The shadow DOM should include all renderable HTML elements save
      standard input controls. The reasoning being is these
      controls are user agent managed in terms of the keyboard and would
      likely conflict with canvas keyboard management.


      The format would be along the following lines:
      <canvas aria-activedescendant="foo">
        <access mode="default">  /*Since canvas is visual this is the
      default mode*/
           <div role="toolbar">
              <div role="tab" tabindex="-1" id="foo">
              </div>
           </div>
        </access>
        <access mode="textual"> /*Here we could place a long description or
      an alternative aria-enabled widget*/
        </access>
        <access mode="auditory">
        </access>
        <access mode="tactile"> /*This is in access for all and we could
      lose it for now for obvious reasons*/
        </access>
        <access mode="olfactory"> /*This is in access for all and we could
      lose it for now for obvious reasons*/
        </access>
        <access mode="visual" type="signlanguage">
        </access>
      </canvas>


      Rich Schwerdtfeger
      Distinguished Engineer, SWG Accessibility Architect/Strategist