Re: Canvas Accessibility Next steps

> Regarding fallback content ...

Please continue with the term fallback as used in html for a long 
time. The term is described in detail with <object> as meaning the 
child html that is exposed when the browser can't do anything 
constructive with the parent. In the most simple case we could see:
<object type='model/x3d+xml' data='scene.x3d'>
<table>... </table>
</object>
where if the browser doesn't do the mime then the html table is shown.
This can be extended to:
<object type='model/x3d+xml' data='scene.x3d'>
<img src='mepic.png' />
<table>... </table>
</object>
where using authorable progressive fallback the table is exposed only 
if both <object> and <img> fail.

Seeing the form:
<canvas width="800" height="450"></canvas>
makes it seem obvious that any 'fallback' content would go as html 
between the tags, the way it is done in <object>. Except for the fact 
that <canvas> is universal and support will always be there no matter 
what so that construct:
<canvas width="800" height="450"></canvas>
<table>... </table>
</canvas>
where table is rendered if the browser doesn't do canvas is really not 
considered that I have seen.

Accessibility for 2D <canvas> is tougher than for other HTML or SVG or 
X3D which have built-in event systems and a scriptable DOM. The 2D 
context is not live in the sense of being updated constantly each 
frame. This tends to limit the scale of interactivity to mostly simple 
stuff. We are now seeing the deep versatility of <canvas> where the 
x3dom.org project is showing the <canvas> element capable of using x3d 
and svg and img and video and audio user code to directly produce an 
interactive <canvas> element. Also shown, and maybe even more fun, 
using html5 xhtml+xml inline user code with X3D and SVG syntax for 
that same purpose. Since svg and x3d are xml dom and can accomodate 
xml ARIA interactive elements these can be treated by aria in the same 
way as other html content.

Thus, the most basic 2D canvas getContext('2d') makes it necessary to 
extend the idea of accessibility to normal people trying to click one 
shape vs another in a <canvas> frame. The desire is to provide a 
dynamic, interactive user interface that operates as expected by a 
user expecting focusable/clickable areas. Somehow we need to produce 
interactive elements from an abstract dynamic procedural graphless 
visualisation created from a script that is long gone and has left no 
traceable trace, except a bitmap. Since a more traditional IMG MAP and 
AREA overlay is not desired we create a 'shadow' dom. If this dom is 
done right, then ARIA can fit right in.

In any case, in my simple view, this is almost not part of the 
accessibility opportunity, but basic engineering to get <canvas> 
context2D elements working as if there was a native dom context 
selectable graph to play with, which there is not. So, this part of 
canvas design is not fallback. Instead, this defines a basic 
connection model to the host DOM as if directly from the internal 
context of the 2D <canvas>. To me, it follows that if we can produce a 
reasonable top-level accessibiity dom, then the rest is easily 
accomodated by xml aria.

When I first saw suggestions in this thread I thought, Great, a 
standard container for non-rendered accessibility information. I 
wanted to start calling it <access> as the top layer of accessibility 
information available for the object or canvas, or whatever else that 
needs it. So, or instance, a canvas element could be;
<canvas ...>
<access> whatever non-rendered html accessibility model could go here 
with ARIA markup?</access>
</canvas>
Where <access> is never rendered, but <access> dom nodes associated 
with the object are created and can be accessed by DOM script 
document.canvas.access.node.attr.value in all cases.

I think the only available place for this 'access' dom is as an 
never-rendered element named <access> which can be included in 
<canvas>, <object>, <embed>, <iframe>, <video>, and any container that 
could use the hints provided in this 'shadow' dom to enhance 
accessibility or interactivity of the frame. In elements other than 
<canvas> context 2D this element could serve as a top-level container 
for a model for interactivity of the 2D screen surface exposed to the 
user. One aspect could be essentially adding some level of interface 
information as a live overlay to the visual frame and providing some 
top-level elements for aria annotation.

The only other reasonable location for this information would be an 
@access='url' attribute that held a link to this abstract model for 
<canvas> context2D accessibilty.

Thanks for the opportunity to discuss this and Best Regards,
Joe
.

Received on Thursday, 21 January 2010 19:35:45 UTC