HTML5 canvas sub DOM

All modern browser implement the HTML5 specification’s canvas element fallback concept. This means that the content inside a canvas elements start and end tags is exposed to assistive technology users even when the browser supports canvas. It also means that any interactive elements, inside a canvas elements start and end tags such as links or form controls will be included in a documents default tab order even when the browser supports canvas.

Canvas has a navigable sub DOM

The HTML5 specification states:

When a canvas element represents embedded content, the user can still focus descendants of the canvas element (in the fallback content). When an element is focused, it is the target of keyboard interaction events (even though the element itself is not visible). This allows authors to make an interactive canvas keyboard-accessible: authors should have a one-to-one mapping of interactive regions to focusable elements in the fallback content. (Focus has no effect on mouse interaction events.)

Which translates as meaning the content inside a canvas element:

If interactive, should be included in the tab order and operable with the keyboard. All content is accessible to assistive technology such as screen readers. So in the canvas example, the text alternative should be announced by screen readers and the links are navigable and operable using the keyboard.

If you are using any modern browser with the keyboard to navigate interactive elements, you can tab to the links in the canvas example. If you are using a screen reader, you can also access the text alternative (in this case) content inside the canvas element.

Canvas example with a text alternative and interactive elements (links) inside the canvas element.

Canvas example HTML code:

<canvas id="example" width="260" height="200">
<h2>Shapes</h2>
<p>A rectangle with a black border. In the background is a pink
circle. Partially overlaying the
<a href="http://en.wikipedia.org/wiki/Circle"
onfocus="drawCircle();" onblur="drawPicture();">circle</a>.
Partially overlaying the circle is a green
<a href="http://en.wikipedia.org/wiki/Square" onfocus="drawSquare();"
onblur="drawPicture();">square</a> and a purple
<a href="http://en.wikipedia.org/wiki/Triangle"
onfocus="drawTriangle();" onblur="drawPicture();">triangle</a>,
both of which are semi-opaque, so the full circle can be seen
underneath.</p>
</canvas>

NVDA announces Canvas sub DOM content (from example page):

“Shapes heading  level 2
A rectangle with a black border. In the background is a pink circle. Partially overlaying the visited  link circle. Partially overlaying the circle is a green visited  link square and a purple visited  link triangle, both of which are semi-opaque, so the full circle can be seen underneath.”

Other examples:

• Hello (hello hello) World! – the dirty <canvas> accessibility hack.
• Funky canvas coat for a wallflower checkbox

Video demo’s:

• NVDA reading canvas sub-DOM content in Firefox
• ZoomText reading canvas sub-DOM content in Firefox

Some Potential Issues

• Where content is currently included in canvas, it is almost exclusively of the “get a better browser that supports canvas” variety, so screen reader users will encounter this when using any modern browser.
• Authors will most likely continue to provide useless information (for screen reader users) as the general definition of “fallback content” in the HTML5 specification is at odds with how canvas content is presented to keyboard and AT users in browsers that support the canvas element and at odds with how the term is used in reference to other embedded content elements where the fallback content is ONLY available to users if the prmary content is not supported.
• Keyboard focus is lost if interactive elements are included inside the canvas, because while elements inside the canvas element are focusable by default, there is no corresponding default indication of focus to identify where current focus is. This means that developers must provide pseudo focus rings that are displayed when an interactive element in the canvas sub DOM receives focus, an example of this is provided triggered by inline (for demo purposes only) onfocus/onblur event handlers. There is a proposal for dedicated canvas API methods for the display of focus rings, but these have not yet been agreed upon or implemented.

Developers Be(a)ware

In Firefox and IE and Chrome and Opera and Safari HTML content inside the canvas element is available at all times to assistive technology users and keyboard users can operate links and controls and they are included in the default tab order. So please provide alternatives to on screen canvas content and interactivity in the canvas sub DOM. DO NOT include a dumb message telling the user that they need to get a browser that supports canvas!

HTML5 definition of ‘fallback content‘

Some embedded content elements can have fallback content: content that is to be used when the external resource cannot be used (e.g. because it is of an unsupported format). The element definitions state what the fallback is, if any.

This general definition of fallback content is problematic, because in the case of canvas and how its use pertains to assistive technology and keyboard users. In modern browsers the <canvas> element is supported, so the content in the sub DOM is not fallback. The example I provided could  have had hit testing on the shapes drawn on the canvas so that a click event could be passed to the links in the sub DOM. The use of the term ‘fallback’ for the contents of the sub DOM helps to mislead developers about sub DOM use. An example of erroneous information is provided in the video: HTML5 Canvas Fallback Content Tutorial