HTML5 Canvas Accessibility in Firefox 13

The recently released Firefox 13 implements 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 in Firefox 13 has a navigable sub DOM

The HTML 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.

Until now, this behaviour had only been implemented in Internet Explorer 9, but with the release of Firefox 13, there are now 2 browsers that  implement support as per the HTML5 specification. So if you are using Firefox 13 or IE9 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="https://en.wikipedia.org/wiki/Circle"
onfocus="drawCircle();" onblur="drawPicture();">circle</a>.
Partially overlaying the circle is a green
<a href="https://en.wikipedia.org/wiki/Square" onfocus="drawSquare();"
onblur="drawPicture();">square</a> and a purple
<a href="https://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.”

Video demo’s:

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

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 Firefox 13 or IE9.
• 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 13+ and IE 9+ HTML content inside the canvas element is now 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 Firefox 13 and IE 9 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