W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Canvas Accessibility Next steps

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Wed, 20 Jan 2010 22:48:09 -0600
To: James Craig <jcraig@apple.com>
Cc: Ian Hickson <ian@hixie.ch>, public-canvas-api@w3.org, HTML WG <public-html@w3.org>
Message-ID: <OFE36A2121.909D55CD-ON862576B2.0017E48A-862576B2.001A6193@us.ibm.com>
Hi James,

Not a problem. The proposal has been out on the canvas public API list for
weeks and you have been unable to attend the last 3 meetings. In fact I
revised my original proposal to accommodate your request to use media
queries as the selection mechanism so that it would be aligned with David
Singer's proposal for video and audo tags. This was posted to the list.
Agendas and minutes have been posted and the public html working group has
been copied.

The Canvas accessibility effort is in fact part of the HTML Accessibility
Task Force. It is recognized that we do now have regular meetings. I
mentioned the Monday meeting and you said you could not guarantee that you
could attend and that you could only guarantee that you could attend ARIA
calls. If you are not attending either the task force meetings or the
canvas accessibility meetings then it is not the fault of either group that
you are not included in consensus. We also discussed if the meeting time
was a problem with people at the call.

I have been tasked by the HTML working group to get the canvas
accessibility issue addressed and we must keep this moving. So, yes I am
going to be a pain. Paul Cotton had asked that we follow through and meet
time lines.

All that said, we are very glad to have your feedback. So let me clarify:

Regarding fallback content I stated that we did not agree with the fallback
content approach. We do not agree that fallback content should reside
between the canvas start and end tags. If a browser is to support HTML 5 it
must support canvas. We felt that accessibility of canvas not be restricted
because a browser cannot support an HTML 5 element. That is a non-compliant
browser. While this was an excellent strategy for the WhatWG while it was
trying to build support for HTML 5 we now have to deliver a working spec.
where browser support all of it or it is not compliant. Otherwise we run
into issues like this where we can't achieve what is necessary due to
having to support a browser which does not even support the specification.

The author is not being mandated to provide anything in content. We are
simply providing a vehicle to best meet the users needs. The CSS Media
query matching would be used to choose alternative renderings.

Now, if the author chooses visual modalities and no specific properties
then NO visual alternatives are chosen and the browser should choose the
default visual rendering with and accessibility mapping using the <default>
shadow DOM approach if it is available.

Also,

The < default> or "shadow DOM" is never to be visually rendered. If an
alternative modality is provided and a CSS media query is provided to
select it then it should be rendered and processed in place of Canvas.

Rich

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist


                                                                           
             James Craig                                                   
             <jcraig@apple.com                                             
             >                                                          To 
                                       Richard                             
             01/19/2010 04:31          Schwerdtfeger/Austin/IBM@IBMUS      
             PM                                                         cc 
                                       Ian Hickson <ian@hixie.ch>,         
                                       public-canvas-api@w3.org, HTML WG   
                                       <public-html@w3.org>                
                                                                   Subject 
                                       Re: Canvas Accessibility Next steps 
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




On Jan 19, 2010, at 11:40 AM, Richard Schwerdtfeger wrote:


      So, we would like the spec to allow for shadow DOM binding to canvas
      where that is possible and for the ability to use CSS Media Queries
      to choose alternative content. This means the DOM elements between
      the <canvas> </canvas> tags must not be used for fallback content but
      rather it be used for content for the accessible binding of a shadow
      DOM to the canvas drawing region and for alternative content:


Was this proposal discussed on the list or just in the call? If it was on
the public-canvas-api list, I apologize for missing it. If it was on the
call, please clarify the pronoun "we", as there were no attendees listed in
the log, and it sounds like you've declared consensus. Even though there is
no official group for canvas accessibility, accepted W3C procedure is that
proposals of this nature should still be discussed through the email list
at least 48 hours prior to declaring consensus.


      such as:

      <canvas>
      <default> /!-- we can chose a different tag name --/
      </devault>
      <visual css media query properties used to select a particular
      alternative modality rendering based on IMS Global Learning
      Consortium Access For All content>
      </visual>
      <visual>
      </visual>
      <audio> /!-- this is a possibility for some users --/
      <audio>
      </canvas>

      Yes, this requires the addition of a <visual> modality tag. At this
      point is agreed upon we are at a stalemate on producing spec. ready
      content to address canvas accessibility.


Declaring a modality-specific tag name–such as visual or audio–seems like a
bad idea. If an author would like their fallback content to be available to
both modalities, this proposal will force them to duplicate that content,
putting excess burden on the developer.

James




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

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

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

Received on Thursday, 21 January 2010 04:48:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:12 UTC