Thinking About HTML 5 canvas Accessibility

The canvas element is a new element of the ‘in progress’ HTML 5 specification, it provides the ability to create dynamically generated graphics in HTML in conjunction with JavaScript. It has rightly generated a lot of interest due to the possibilities it presents, canvas “can be used for rendering graphs, game graphics, or other visual images on the fly”. While its creative features are sophisticated, its ‘feature’ (duplicate all canvas content as HTML inside the canvas element) for providing an accessible content can best be described as a primitive example of ‘bolt on’ accessibility.

canvas Accessibility Issues

I consider canvas accessibility (or lack of it) one of the major accessibility issues in the current HTML 5 specification and one that will need to be resolved, so I raised the topic of canvas accessibility on the HTML WG mailing list a few months ago:

Are there plans to provide mechanisms to add accessibility hooks for content produced using canvas? As providing a secondary accessible version of an application such as bespin seems like a non starter, and is a prime example of the sort of “bolt on” accessibility that HTML5 was trying to move away from.

I have not yet received an answer.

Issues and Suggestions

Text in canvas

There is a native method to display text in canvas (example of its use: Cufón), but no native method to output text as fallback. So the developer using canvas to replace text either needs to implement a method using scripting or manually add the fallback text.

It is suggested that to make it practical for developers to provide fallback for disabled users who cannot access the text content directly, a native method that outputs the text as fallback is added to the canvas API.

Images in canvas

There is a native method for inserting images into canvas (Example of its use: Canvas Slideshow (with HTML5 canvas), but no methods to add a text alternative to the images or method to output such images as fallback. So the developer using images in canvas either needs to implement a method using scripting or manually add the fallback images and text alternatives.

It is suggested that to make it practical for developers to provide fallback for disabled users who cannot access the image content directly a native method that allows the addition of text alternatives and an output method that inserts img elements as fallback content, is added to the canvas API.

User interface elements in canvas

canvas can be used to create interactive interfaces (example of its use: bespin), but there are no methods to assign roles, states and properties to areas of a canvas that represent widgets, controls or links. So the developer who wants to create an accessible interface has to duplicate the content of the canvas interface using HTML elements that provide native roles, states and properties.

It is suggested that to make it practical for developers to provide information about UI elements to disabled users who cannot access information visually, native methods be provided that allow for the identification of the roles, states and properties of user interface elements displayed on a canvas, futhermore a method to define discrete focusable areas of the canvas be provided.

A crude example of some of the features required in canvas can be illustrated using a HTML image map. The example uses a canvas pie menu demonstration by Ben Galbraith to which a transparent image map has been added. The image map provides keyboard access to segments of the pie menu, it also provides information about their role and state of each and name (text alternative) for each segment. Note: Use of this image map technique, while useful for illustrative purposes is not proposed as a practical solution.

Further Reading

• 4.11.4 The canvas element
• Notes on accessibility of text replacement using HTML5 canvas
• Thoughts towards an accessible canvas