- From: Joe D Williams <joedwil@earthlink.net>
- Date: Sat, 9 Jan 2010 20:40:18 -0800
- To: "Ian Hickson" <ian@hixie.ch>, "Richard Schwerdtfeger" <schwer@us.ibm.com>
- Cc: <public-canvas-api@w3.org>, <public-html@w3.org>
> <canvas> <fallback> I think this is not 'fallback', it is an alternative/additive mapping of the visual elements, but the fallback is what happens when everything else fails and the 'fallback' content is used instead. Great you are showing some augmentation details useful for making the canvas interactive and I think it is a new category of information supporting <canvas> accessibility. Why not call it something that indicates a certain category of information that is processed by certain types of interfaces like access with some attritues, and content like you showed. Historically, fallback is what happens when the host cannot produce any rendering of the parent structure. Instead, this is a target set of information aimed at accessibility. This style of defining a descriptive container for access info could also be leveraged into <object>, <video>, and <audio> to contain alternative interface info. Thanks and Best Regards, Joe. ----- Original Message ----- From: "Richard Schwerdtfeger" <schwer@us.ibm.com> To: "Ian Hickson" <ian@hixie.ch> Cc: <public-canvas-api@w3.org>; <public-html@w3.org> Sent: Saturday, January 09, 2010 5:09 PM Subject: Re: Fw: Proposal: Canvas accessibility and a media querries approach for alternative content (Action Item 6 in the HTML Accessibility Task Force) Rich Schwerdtfeger Distinguished Engineer, SWG Accessibility Architect/Strategist Ian Hickson <ian@hixie.ch> wrote on 01/08/2010 04:30:21 PM: > Ian Hickson <ian@hixie.ch> > 01/08/2010 04:30 PM > > To > > Richard Schwerdtfeger/Austin/IBM@IBMUS > > cc > > "public-canvas-api@w3.org" <public-canvas-api@w3.org>, > public-html@w3.org > > Subject > > Re: Fw: Proposal: Canvas accessibility and a media querries approach > for alternative content (Action Item 6 in the HTML Accessibility > Task Force) > > On Fri, 8 Jan 2010, Richard Schwerdtfeger wrote: > > > > > > > > It is not like XBL 2 as the XBL 2 shadow tree cannot be > > > > accessed in > > > > the browser DOM. > > > > > > It _is_ exposed to script, if that's what you mean. > > > > As I understood it, and I may be wrong, the XBL shadow DOM was not > > part > > of the actual web page DOM ... I could walk the main DOM tree to > > access > > these DOM elements in script. If it is then yes it is like the XBL > > shadow DOM and we should stay with the term shadow DOM. > > The XBL2 Shadow Tree is exposed on the shadowTree IDL attribute on > the > DOM of the bound element. > > > > Would a DOM inspector get the subtree DOM? > > That depends on the DOM inspector. There's no reason why one > shouldn't. > > > > > From your description it just sounds like the regular DOM. Maybe > > > "fallback subtree DOM", if you feel the need to qualify the > > > term. > > > > Yes, I feel we need to qualify this. > > Fair enough. I strongly encourage you to use the term "fallback > subtree > DOM" or something along those lines, as IMHO it is more accurate > than > "shadow DOM". > ok. Do you see any use for this other than accessibility? > > > If we were to expand this to the entire page that would be great > > but we > > also need the ability to replace specific components of the page > > with > > alternatives. For example, parts of the page may meet the user's > > need as > > is where other parts do not. > > Could you give a concrete example where there is alternative content > that > could not be given in the <canvas> element's fallback content and > would > not be appropriate for all users, such that you would want to > actively > hide it from some users? I'm having difficulty imagining what this > case > would be. The examples I've seen so far, and the user cases I > studied when > designing the <canvas> accessibility story several years ago, all > fall > into the two categories of either (a) appropriate for <canvas> > fallback > contents or (b) suitable for all users. Sure, but by hiding I mean the actual visual rendering would be the canvas. An author may wish to render their own toolbar, like in Bespin, but because it is just a collection of polylines, text, images, and so on it is inaccessible. To make it accessible, we would simply create a fallback DOM that looked something like the following: <canvas> <fallback> <div role="toolbar"> <div tabindex="0" role="button" aria-pressed="false">Double Space</div> <div tabinex="-1" role="button" aria-pressed="false">bold</div> <div tabindex="-1" role="button" aria-pressed="true">bulleted list</div> </div> <fallback> </canvas>> The author would simply draw on the canvas and update the fallback DOM which would be the accessible tree version of the canvas toolbar. The fallback DOM would be mapped to the accessibility API. Visual focus on the toolbar would be rendered in JavaScript. However, this fallback solution has no styling as the actual rendering is being performed on the canvas. There is no reason to use a style sheet on the fallback DOM. AS the fallback DOM is not drawn in a consumable way (except via the canvas) it is not suitable to all users. However, an browser can map the fallback DOM to the platform accessibility API and transform them into accessible objects for access by an assistive technology. Now, I think we are almost on the same page regarding alternative visualizations. The subway alternative visualization I provided was not only accessible but would also be suitable for all users. Yet, for some users the richer graphical version of the subway map on the canvas may be more usable to others. It is simply a personal preference. I think where we may differ is that while alternative visualizations would benefit all users and that they could be applied to the entire page, it is not not necessary that alternative modalities be applied only to the entire page. There is tremendous value add in providing alternatives to individual regions like canvas, video, and audio within the page as the rest of the page may adequately meet the needs of the modality preferred by the user. > > -- > Ian Hickson U+1047E )\._.,--....,'``. > fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ > ;`._ ,. > Things that are impossible just take longer. > `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 10 January 2010 04:40:53 UTC