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/07/2010 11:31:53 PM:

> Ian Hickson <ian@hixie.ch>
> 01/07/2010 11:31 PM
>
> To
>
> Richard Schwerdtfeger/Austin/IBM@IBMUS
>
> cc
>
> public-html@w3.org, "public-canvas-api@w3.org" <public-canvas-api@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 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. From reading SVG's information it would appear closer to that
in that the author has the ability to manipulate it and access it during
normal web page operation.

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.

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.

>
> > In those scenarios it will be necessary to provide alternative content.

> > So, we are investigating building off Dave Singer's media query
approach
> > to accessibility for the video tag.
> >
> > In this scenario we would need to introduce a visual media type to
> > provide alternative visualization in the HTML markup whose selection
> > would be based on properties defined in the Access For All standards
> > effort. The caveat being the following:
> >
> > The HTML 5 specification defines a source element which specifies,
> > although not implicitly stated, a complete file. Today much of the
> > visual content is delivered as fragments and, like a mashup, we will
> > need to pull in fragments for alternative content that can be used in
> > the markup in place of canvas. A concrete use case would be a grid
which
> > replaces a pie chart. An entire page is not required for that.
> >
> > If it is visual content we would need to decide whether to store it in
> > an IFrame in some instances:
> >
> > - Full pages
> > - Fragments where there may be id conflicts or where security will be a
> > concern
> >
> > 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.



The browser would change the content used and rendered based on the CSS
media query chosen for canvas by accessing the althernative content and
rendering it in an IFrame in place of canvas on behalf of the user.

Does this help?

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