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
canvaselement represents embedded content, the user can still focus descendants of the
canvaselement (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
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 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.”
- Hello (hello hello) World! – the dirty <canvas> accessibility hack.
- Funky canvas coat for a wallflower checkbox
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 HTML specification is at odds with how
canvascontent is presented to keyboard and AT users in browsers that support the
canvaselement 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 primary content is not supported.
- Keyboard focus is lost if interactive elements are included inside the canvas, because while elements inside the
canvaselement 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/onblurevent handlers. There is a dedicated
canvasAPI methods for Drawing focus rings and scrolling paths into view, these are now implemented in modern browsers.
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 an asinine 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