- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 8 Jan 2010 20:50:43 +0000 (UTC)
- To: Richard Schwerdtfeger <schwer@us.ibm.com>
- Cc: "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-html@w3.org
On Fri, 8 Jan 2010, Richard Schwerdtfeger wrote: > > On Thu, 7 Jan 2010, Richard Schwerdtfeger wrote: > > > > > > In addition to employing a shadow DOM to produce an accessible > > > canvas solution there may be situations where that approach will not > > > be appropriate depending on the heavy graphics nature of canvas. > > > > By "shadow DOM" do you mean the normal DOM as currently specified in > > the spec, something like SVG's shadow DOM, or something like XBL2's > > shadow DOM? It's still unclear what you mean by the term. If you don't > > mean the same as SVG or XBL2, please use another term, as it is very > > confusing. > > 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. > Essentially the shadow DOM would reside within the canvas tags but not > be visible to a user. Authors would treat it much like an accessibility > tree but the rendering would be in the canvas area. An author would use > divs and spans with aria markup to convey the accessibility information > of a rendered toolbar in the canvas area. Keyboard navigation would be > through the shadow DOM and it would be up to the author to render its > represntation in the canvas area, including drawing visible focus. > Microsoft, Apple, and Mozilla have been asked if there are issues with > using standard input controls in the shadow DOM area to represent the > visual rendering. This appears to be exactly what the spec already requires; could you elaborate on whether (and if so, how) this differs from the current requirements in the specification? > We used the term shadow as it is not visible on the screen. I believe we > would be open to giving it a different term if that explanation is still > confusing. >From your description it just sounds like the regular DOM. Maybe "fallback subtree DOM", if you feel the need to qualify the term. > > > Do you see any issues/concerns with: > > > > > > - Introducing a visual media type to HTML 5 > > > - expanding the specification to ensure that source fragments, for > > > visual modalities, are allowed and allowing the author to specify > > > whether the they be stored in an IFrame. > > > > Whenever an author uses <canvas>, he either provides an unscripted > > alternative (that doesn't use <canvas>), or he can rely on using > > script to trigger appropriate rendering. Because of this, it's unclear > > to me why we would need anything additional to support this case. > > > > Could you maybe take a concrete example of <canvas> use and show how > > you envisage an accessible alternative as you describe above will be > > provided? (As opposed to the way the spec currently suggests it should > > be done?) I think that would greatly clarify what it is you are > > suggesting. > > Sure. > > Let's say that the default rendering is visual rendering of a subway > map. This is inaccessible to a blind user. From a categorization > perspective, one would consider the canvas rendering of a subway map as > a complex visualization. Rather than use the shadow DOM approach (which > in this case I believe is impractical) and have the author try to create > an accessible DOM version of a subway map visual rendering an > alternative visual modality would be provided with a set of properties > that defined its supported features. > > Within the alternative modality we could reference a URL with an > alternative rendering for the subway map the alternative rendering might > allow the user to enter the start and end location and generate the > subway directions in HTML text on the page. Longer term the alternative > visualization may allow for geo location to be used to help in the > direction generation based on where the user wishes to go and so on. The > ouput would be basic html 5 elements and input controls with script for > updating and accessing geo location information. This would be more of a > text equivalent for a complex visualization that support > interoperability with assistive technologies (one of the CSS properties) > and could in fact be in high contrast. This sounds like something that would be useful to all users; wouldn't it be sufficient to just link to this alternative view from the page with the canvas, so that any user can chose to use this view? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 8 January 2010 20:51:14 UTC