W3C home > Mailing lists > Public > public-canvas-api@w3.org > January to March 2010

HTML 5 canvas accessibility proposal with spec. ready html

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 19 Feb 2010 18:10:48 -0700
To: David Bolter <david.bolter@gmail.com>, Charles McCathieNevile <chaals@opera.com>, cyns@exchange.microsoft.com, Steven Faulkner <faulkner.steve@gmail.com>, Frank Olivier <franko@microsoft.com>, jcraig@apple.com, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-canvas-api-request@w3.org, surkov.alexander@gmail.com, cooper@w3.org
Message-ID: <OF6106E212.B2DD671D-ON862576CF.006187C7-862576D0.00067A81@us.ibm.com>

Below is the proposal and attached HTML file with spec. ready text denoted
by <ZZ> and </ZZ> for final review on Monday's canvas accessibility subteam
call (incorporating feedback from David Bolter).


When possible a facility should be provided to make <canvas> directly
accessible to assistive technologies in such a way that an accessibility
validator may detect the accessible representation the canvas rendering .
The accessibility
representation should be such that keyboard navigation of <canvas> be
consistent
with standard HTML navigation in the DOM and as such the author should be
able to use the area between the <canvas> </canvas> tags to implement this
accessible rendering. The challenge being that the author also uses the
same <canvas> subtree to represent fallback content. The fallback subtree
differs from the accessible <canvas> subtree in that the accessible
<canvas> subtree is designed to have its rendering directly drawn to the
<canvas> whereas the fallback subtree is not.

The determination of the disposition of the <canvas> subtree can be
done at load time. Therefore, to indicate to assistive technologies
and test tools that the <canvas> subtree is a directly accessible binding
of <canvas> we would like to introduce a new canvas attribute called
adom. When set to true it indicates that the canvas subtree is
to be used as a directly keyboard operable accessible subtree of canvas".
Another important reason for it being an attribute (as opposed to a
separate element) is because there is likely no need for the DOM to contain
both 'fallback content' and 'shadow DOM content' at the same time.
"Progressive
enhancement can be achieved since the fallback content can come over the
wire in the HTML
source and script can determine whether the the canvas feature is supported
by the browser by using
the canvas.getContext() method. If it returns null canvas is not supported.
If canvas
is supported then the author can replace or modify, or re-purpose the
fallback
content to be shadow DOM content (and update the new attribute) when it
initializes the canvas.

(See attached file: canvaselement-issue74)


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist




Received on Saturday, 20 February 2010 01:11:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 01:11:46 GMT