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

Re: Canvas Accessibility Next steps

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Sun, 24 Jan 2010 16:44:39 -0600
To: Maciej Stachowiak <mjs@apple.com>
Cc: Ian Hickson <ian@hixie.ch>, James Craig <jcraig@apple.com>, public-canvas-api@w3.org, HTML WG <public-html@w3.org>
Message-ID: <OF4171A8D1.CC48A1D7-ON862576B5.007BB5E3-862576B5.007CF012@us.ibm.com>

Hi Maciej,

I understand. I have two concerns with this approach:

1. id names are not reserved. Potentially, and although remote, an author
could randomly have chosen those id's.  We want to have reserved CSS
Properties that may applied to any web page.
2. Authors may wish to choose a src file to be rendered. Companies are
providing public APIs out there to provide reusable content such as a
Google Map and with a small parameter change the driving directions. We
should allow authors to provide entire remote fragments as alternatives to
canvas to pul into a web page.

Here are three versions of the driving directions:

http://maps.google.com/maps?f=d&output=html&hl=en&q=3832+royal+troon+drive
+Round+Rock%2C+78664+to+11501+burnet+road+austin
+78758&dirmode=walking&ie=UTF8&dirflg=w

http://maps.google.com/maps?f=d&output=map&hl=en&q=3832+royal+troon+drive
+Round+Rock%2C+78664+to+11501+burnet+road+austin
+78758&dirmode=walking&ie=UTF8&dirflg=w

http://maps.google.com/maps?f=d&output=kml&hl=en&q=3832+royal+troon+drive
+Round+Rock%2C+78664+to+11501+burnet+road+austin
+78758&dirmode=walking&ie=UTF8&dirflg=w


Rich:

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist


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





On Jan 22, 2010, at 2:36 PM, Richard Schwerdtfeger wrote:>,

      Let's discuss on Monday's call Canvas accessibility call. The CSS
      media query for HTML 5 is bound to there being things like an audio
      and video media element. The media query is used to select the
      appropriate content. This is why we need to have a visual ( or screen
      media type) as an alternative. I would be happy to have the media
      types as DOM attributes but the current HTML 5 spec. defines media
      types as elements in the DOM instead. I am trying to stay consistent.
      HTML 5 defines a <video> and <audio> tag to define media types vs.
      <div media="audio">/

Actually, for purposes of showing or hiding different chunks of content,
you can just use CSS media queries through straight CSS.

Let's say you have this markup:

<canvas id="my-app-ui">
<div id="visual">
...
</div>
<div id="high-contrast">
....
</div>
<div id="audio">
...
</div>
</canvas>

You can just use this style:

<style>
#my-app-ui > #visual { display: block; }
#my-app-ui > #high-contrast { display: none; }
#my-app-ui > #audio { display: none; }
@media (aural) {
  #my-app-ui > #visual { display: none; }
  #my-app-ui > #high-contrast { display: none; }
  #my-app-ui > #audio { display: block; }
}
@media (high-contrast) { /* suggested future CSS media type */
  #my-app-ui > #visual { display: none; }
  #my-app-ui > #high-contrast { display: block; }
  #my-app-ui > #audio { display: none; }
}
</style>

This technique is fully general and can apply to selection from multiple
content sets in just about any context. The only reason <video> and <audio>
need a special feature for their <source> elements is because in that case,
the choice is not a matter of whether an element is rendered, but rather of
choosing a media item to be presented by a parent element. But <canvas> can
do the same thing without the need for special features.

Regards,
Maciej





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

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

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

Received on Sunday, 24 January 2010 22:45:20 UTC

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