developer.paciellogroup.com

Notes on accessibility of text replacement using HTML5 canvas

Steve Faulkner

Roger Johannson recently blogged on issues with Cufon Accessibility in relation to Assistive Technology, which is well worth a read. It prompted me to do a little testing:

One of the examples of the utility of canvas that has emerged is its use in rendering text using custom fonts. Cufon, for example, is a text replacement tool using canvas for browsers that support it and VML (for Internet Explorer). So it is quite obvious that the advice in the HTML 5 specification to refrain from using canvas “when a more suitable element is available” is likely to be widely ignored, as can be seen from examples of use linked from the Cufón Demos page.

Providing an Accessible Alternative

From a reading of the HTML 5 specification, providing an accessible alternative, to text rendered as a bitmap using canvas, can in theory be handled easily:

When authors use the canvas element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element’s fallback content.

So providing a text fallback for a canvas based text replacement like Cufón can be achieved by placing text inside the canvas element:

<canvas> text </canvas>

Other HTML elements can be included inside the canvas element:

<canvas><p> text </p></canvas>

User Agent Behaviour

The results of this should be:

  • For browsers which support canvas and have JavaScript enabled, the content inside the canvas element is not displayed.
  • For browsers that do not support canvas or have JavaScript disabled, the content inside the canvas element is displayed.
  • Assistive technologies such as screen readers can announce the content inside the canvas element, accessing it via the HTML DOM.

These are the results for browsers in most cases, but Firefox does not display the fallback content when JavaScript is disabled. Unfortunately at this point in time, no assistive technology (that I know of) announces the content contained within the canvas element in browser with canvas support. I contacted the developers of JAWS (no reply), Window Eyes (no firm date for support) and NVDA (initial investigation indicates there is an issue in Firefox). So the reality for AT users is, if they use a browser that supports canvas, an accessible alternative is not currently available to them if the content is contained within the canvas element.

Providing an accessible alternative when the canvas element is self closing

In the case of Cufón, the canvas element is added to the page using document.createElement("canvas"). This method does not result in an element with start and end tags, but rather:

<canvas />

Adding a canvas element to a page using scripting appears to be quite a common method, so in many cases fallback will not be contained within the canvas element. Cufón does add ‘fallback’ text which is hidden from visual display using the CSS ‘display:none‘, unfortunately this also hides the text from AT that supports CSS (JAWS for example).

<canvas /> <span style="display:none"> text </span>

The use of ‘display:none’ in Cufón appears to be due to the reason for the provision of the fallback being for printing purposes (text is set to be displayed in the print stylesheet), not for providing an accessible text alternative for the images of text.

For the Cufón fallback text, or any accessible content alternatives for <canvas /> to be hidden from display, but available to AT, the content should be hidden offscreen using CSS:

Example class for hiding content offscreen:

span.fallback{
position: absolute;
left: -999em;
width: 0.1em;
overflow: hidden;
}

<canvas /> <span class="fallback"> text </span>

Any span element that is assigned the ‘.fallback’ class is positioned absolutely outside of the main viewport. The content of the span is very slim with its overflow property set to hidden to help ensure that the content doesn’t bleed into the main viewport.

Further Reading