- 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 <mjs@apple.com> Sent by: To public-canvas-api Richard -request@w3.org Schwerdtfeger/Austin/IBM@IBMUS cc Ian Hickson <ian@hixie.ch>, James 01/24/2010 08:28 Craig <jcraig@apple.com>, PM public-canvas-api@w3.org, HTML WG <public-html@w3.org> Subject 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. <rich> 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. </rich> 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). <rich> I agree. I came to the conclusion about the IFrame after sending the note and took that approach on Monday's call. <rich> 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 What is Google's current UI to let users choose between these? (I honestly don't know.) <rich> 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. </rich> Regards, Maciej
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic15966.gif
- image/gif attachment: ecblank.gif
Received on Tuesday, 26 January 2010 15:57:33 UTC