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

public-canvas-api-request@w3.org wrote on 01/08/2010 02:50:43 PM:

> Ian Hickson <ian@hixie.ch>
> Sent by: public-canvas-api-request@w3.org
>
> 01/08/2010 02:50 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:
> > > 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.
>
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.

Would a DOM inspector get the subtree DOM?

>
> > 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?
>
I guess I am confused - are you referring to our requirements? If so, then
yes it is not different.
>
> > 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.
>
Yes, I feel we need to qualify this.
>
>
> > > > 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?
>
I am glad you raised that point. It is definitely a benefit to all users.
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.

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>