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.


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

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

Received on Friday, 8 January 2010 05:32:26 UTC