- 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
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic32495.gif
- image/gif attachment: ecblank.gif
Received on Sunday, 24 January 2010 22:45:25 UTC