- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Wed, 20 Jan 2010 22:48:09 -0600
- To: James Craig <jcraig@apple.com>
- Cc: Ian Hickson <ian@hixie.ch>, public-canvas-api@w3.org, HTML WG <public-html@w3.org>
- Message-ID: <OFE36A2121.909D55CD-ON862576B2.0017E48A-862576B2.001A6193@us.ibm.com>
Hi James, Not a problem. The proposal has been out on the canvas public API list for weeks and you have been unable to attend the last 3 meetings. In fact I revised my original proposal to accommodate your request to use media queries as the selection mechanism so that it would be aligned with David Singer's proposal for video and audo tags. This was posted to the list. Agendas and minutes have been posted and the public html working group has been copied. The Canvas accessibility effort is in fact part of the HTML Accessibility Task Force. It is recognized that we do now have regular meetings. I mentioned the Monday meeting and you said you could not guarantee that you could attend and that you could only guarantee that you could attend ARIA calls. If you are not attending either the task force meetings or the canvas accessibility meetings then it is not the fault of either group that you are not included in consensus. We also discussed if the meeting time was a problem with people at the call. I have been tasked by the HTML working group to get the canvas accessibility issue addressed and we must keep this moving. So, yes I am going to be a pain. Paul Cotton had asked that we follow through and meet time lines. All that said, we are very glad to have your feedback. So let me clarify: Regarding fallback content I stated that we did not agree with the fallback content approach. We do not agree that fallback content should reside between the canvas start and end tags. If a browser is to support HTML 5 it must support canvas. We felt that accessibility of canvas not be restricted because a browser cannot support an HTML 5 element. That is a non-compliant browser. While this was an excellent strategy for the WhatWG while it was trying to build support for HTML 5 we now have to deliver a working spec. where browser support all of it or it is not compliant. Otherwise we run into issues like this where we can't achieve what is necessary due to having to support a browser which does not even support the specification. The author is not being mandated to provide anything in content. We are simply providing a vehicle to best meet the users needs. The CSS Media query matching would be used to choose alternative renderings. Now, if the author chooses visual modalities and no specific properties then NO visual alternatives are chosen and the browser should choose the default visual rendering with and accessibility mapping using the <default> shadow DOM approach if it is available. Also, The < default> or "shadow DOM" is never to be visually rendered. If an alternative modality is provided and a CSS media query is provided to select it then it should be rendered and processed in place of Canvas. Rich Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist James Craig <jcraig@apple.com > To Richard 01/19/2010 04:31 Schwerdtfeger/Austin/IBM@IBMUS PM cc Ian Hickson <ian@hixie.ch>, public-canvas-api@w3.org, HTML WG <public-html@w3.org> Subject Re: Canvas Accessibility Next steps On Jan 19, 2010, at 11:40 AM, Richard Schwerdtfeger wrote: So, we would like the spec to allow for shadow DOM binding to canvas where that is possible and for the ability to use CSS Media Queries to choose alternative content. This means the DOM elements between the <canvas> </canvas> tags must not be used for fallback content but rather it be used for content for the accessible binding of a shadow DOM to the canvas drawing region and for alternative content: Was this proposal discussed on the list or just in the call? If it was on the public-canvas-api list, I apologize for missing it. If it was on the call, please clarify the pronoun "we", as there were no attendees listed in the log, and it sounds like you've declared consensus. Even though there is no official group for canvas accessibility, accepted W3C procedure is that proposals of this nature should still be discussed through the email list at least 48 hours prior to declaring consensus. such as: <canvas> <default> /!-- we can chose a different tag name --/ </devault> <visual css media query properties used to select a particular alternative modality rendering based on IMS Global Learning Consortium Access For All content> </visual> <visual> </visual> <audio> /!-- this is a possibility for some users --/ <audio> </canvas> Yes, this requires the addition of a <visual> modality tag. At this point is agreed upon we are at a stalemate on producing spec. ready content to address canvas accessibility. Declaring a modality-specific tag name–such as visual or audio–seems like a bad idea. If an author would like their fallback content to be available to both modalities, this proposal will force them to duplicate that content, putting excess burden on the developer. James
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic06845.gif
- image/gif attachment: ecblank.gif
Received on Thursday, 21 January 2010 04:48:51 UTC