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

Re: Canvas Accessibility Next steps

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Tue, 26 Jan 2010 09:56:44 -0600
To: Maciej Stachowiak <mjs@apple.com>
Cc: Ian Hickson <ian@hixie.ch>, James Craig <jcraig@apple.com>, public-canvas-api@w3.org, public-canvas-api-request@w3.org, HTML WG <public-html@w3.org>
Message-ID: <OFBDAB2BCF.369C9B66-ON862576B7.0056FF04-862576B7.0057978D@us.ibm.com>

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

             Maciej Stachowiak                                             
             Sent by:                                                   To 
             public-canvas-api         Richard                             
             -request@w3.org           Schwerdtfeger/Austin/IBM@IBMUS      
                                       Ian Hickson <ian@hixie.ch>, James   
             01/24/2010 08:28          Craig <jcraig@apple.com>,           
             PM                        public-canvas-api@w3.org, HTML WG   
                                       Re: Canvas Accessibility Next steps 

On Jan 24, 2010, at 2:44 PM, Richard Schwerdtfeger wrote:>,

      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.

That's true for the id names. But it's not true for the media type names.
What the user would choose via accessibility preferences and choice of
assistive technologies is what media type they are browsing with. The id
names are not exposed to the user, they are just a mechanism to bind to
media-type-specific rules. I could just as well have chosen class names or
any other styling hook that CSS has available.


I have the same problem with class names. Again, I think we have come to a
happy middle ground by defining standard attributes for choosing content vs
ids and this in combination with your use of media type names should work
for us.


      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.

Authors could do that with an <a> element to link to the alternate version,
or an <iframe> to embed it, or even a script to redirect automatically.
These options could either be placed in an element that has an associated
media query (either inside or outside the <canvas>), or just presented to
all users (either outside the canvas so everyone gets the visual rendering,
or just inside so everyone gets an associated model object).

I agree. I came to the conclusion about the IFrame after sending the note
and took that approach on Monday's call.

      Here are three versions of the driving directions:




What is Google's current UI to let users choose between these? (I honestly
don't know.)


There is not and we need a vehicle to make the choice - at least to choose
between a text version (driving directions) vs. a roadmap image. By
defining resource attributes IMS properties and using those in concert with
media names we can put the decision in the hands of the user with the media
query. Google provides the service and people use them as they see fit.



(image/gif attachment: graycol.gif)

(image/gif attachment: pic15966.gif)

(image/gif attachment: ecblank.gif)

Received on Tuesday, 26 January 2010 15:57:31 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:08 UTC