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

HTML 5 canvas

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Thu, 23 Dec 2010 14:12:30 -0600
To: "Shawn Warren" <swarren@aisquared.com>
Cc: janina@rednote.net, chuck@jumis.com, public-canvas-api@w3.org
Message-ID: <OF4F72E8FE.125DCAF7-ON86257802.006B919E-86257802.006F01F1@us.ibm.com>

Hi Shawn,

I am working on HTML 5 canvas accessibility in the W3C. I am not sure how
much you know about the new <canvas> element but essentially it allows an
author to draw whatever they want on a drawing surface in your web page.
Our approach to making it accessible is to create a "shadow" DOM inside
canvas were we create a number html elements that represent what you are
seeing on the drawing surface and which the browser would map to the
platform accessibility API supported by the browser. Something like:

  <div role="checkbox" aria-checked="true" tabindex="0">

Each of the elements in the shadow DOM (the DOM inside the canvas tags that
is not visible) would have a one to one correspondance to what is drawn for
checkboxes on canvas. Elements within the shadow DOM would follow normal
keyboard processing rules that are followed by the rest of the web page.

For selected text, grammatical error identification, and spelling errors we
can also mark content in the shadow DOM to populate the accessibility API
as to what constitutes the logical selected text, caret position, etc. in
the <canvas> shadow DOM should rich text editing to be performed.

We would then have a set of APIs to set the caret and focus ring positions
on the physical canvas that would then map to platform accessibility API to
allow a magnifier to follow the focus position  (focus rings and caret

example: <mark aria-invalid="grammar">See run Spot</mark>

It occurred to me, we might have another complication with screen
magnifiers in that if you think of model view controller architecture the
canvas is a physical rendering of the shadow DOM and the physical screen
location of all the elements in the shadow DOM would not align properly.
This mapping is normally done automatically by the browser when it renders
non-canvas HTML elements. So, I am very concerned at having to ask the
author to set the screen position of each shadow DOM element and manage

So, my questions to you are:

- Do you have to know the screen location of all the content even when it
is not focused?
- If you do, what is the minimal amount of information you would need?

In order to have web application support of ATs we need to be able to
minimize the impact to development so I am trying to find a solution that
will satisfy both AT and developer.

Best Regards,

Rich Schwerdtfeger
CTO Accessibility Software Group
Received on Thursday, 23 December 2010 20:13:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:51 UTC