RE: HTML 5 canvas

We do need the screen location of all content with or without focus, the
main reason is for highlighting and tracking while we read or browse a
page. For this we would need 

-          the bounding rectangle of each element in screen coordinates
(or client coordinates if we know the relative top-left) 

-          a way to scroll an element into view either to top-left or
bottom-right (depending on navigation direction while browsing a page)

 

Shawn

 

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] 
Sent: Thursday, December 23, 2010 3:13 PM
To: Shawn Warren
Cc: janina@rednote.net; chuck@jumis.com; public-canvas-api@w3.org
Subject: HTML 5 canvas

 

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:

<canvas>
<div role="checkbox" aria-checked="true" tabindex="0">
<TEXTAREA NAME="comments" COLS=40 ROWS=6></TEXTAREA>
</canvas>

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

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

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



Rich Schwerdtfeger
CTO Accessibility Software Group