The HTML5 <canvas> element provides authors with a drawing API they can use to create dynamic, scriptable, interactive bitmap images.
There is virtually no limit to what authors can draw on the <canvas>, including the number of paths, how users interact with those paths, and how those items may change over time.
However, the dynamic nature of the <canvas> element has made it difficult, if not impossible, to use in applications that need to be accessible to people with disabilities. To be accessible, it must meet the following principles:
- Providing alternative content for what is drawn on the <canvas>
- Exposing the location of a path drawn on the <canvas> to assistive technologies
- Visually indicating whether or not that path had keyboard focus
The <canvas> element allows authors to put HTML content between its opening and closing tags ('fallback content'), which provides an alternative for non-text content. However, without a method for programmatically associating this content with regions on the <canvas>, and visually indicating when these regions have focus, dynamic and interactive <canvas> applications cannot be fully accessible.
The Task Force
The Canvas Task Force of the W3C's HTML Working Group has recently added two new features to the Canvas 2D specification that attempt to solve these problems: a method for programmatically linking a region of the *canvas* with a particular piece of fallback content, and one for visually indicating if that region has keyboard focus.
The addHitRegion() method can be passed the ID of a corresponding element represented in the fallback content. When a keyboard or screen reader user interacts with fallback content, the location information reported to the Accessibility API is that of the corresponding hit region.
Screen magnification software can then pan and zoom to the location of the region drawn on the <canvas>, rather than the location of the textual equivalent.
Authors can also call the drawFocusIfNeeded() method after drawing a path to the <canvas>. This instructs the browser to check if the associated fallback content has focus, and if it does, to draw a focus indicator (a dotted or solid line) around that path.
These two features are currently in the Candidate Recommendation stage of the W3C Technical Report development process.
Words: Mark Sadecki
Mark Sadecki is the accessibility coordinator at edX, and an invited expert in W3C's HTML Working Group. He participates in the HTML Accessibility Task Force and the Canvas Task Force. Follow him on Twitter at @cptvitamin. This article appeared first in issue 262 of net magazine.
Like this? Read these!
