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. `._.-(,_..'--(,_..'`-.;.'