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:
> > 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