- 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:31 UTC