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

Categories: Technical
Tags:

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

Comments

John Foliot says:

Some thoughts in another vein (from March of this year): https://john.foliot.ca/thoughts-towards-an-accessible-canvas/

canvas is and will continue to be the biggest accessibility concern in HTML5 (followed closely by video and audio) as all of these enhancements have not properly spec’ed the accessibility requirements in their roll-out. The biggest problem however is that they are in production now, minus their accessibility pieces. It’s a sad state.

stelt says:

accessibility and graphics … at least mention SVG

Brad Neuberg says:

I’m very surprised you didn’t mention SVG. Accessibility is one of the strong reasons to use SVG. It’s supported in all the same browsers as Canvas.

steve faulkner says:

Hi Stelt and Brad,
I didn’t mention SVG as the post subject is canvas accessibility, recommending people use SVG instead of canvas does nothing to improve the accessibility of canvas.