What the canvas element means for accessibility

By Creative Bloq Staff
( netmag )
published

Mark Sadecki discusses two features of HTML5’s canvas element that help make it accessible to users with disabilities.

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 (opens in new tab) 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 (opens in new tab) 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 (opens in new tab) 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 (opens in new tab). Follow him on Twitter at @cptvitamin. This article appeared first in issue 262 of net magazine.

Like this? Read these!

Thank you for reading 5 articles this month* Join now for unlimited access

Enjoy your first month for just £1 / $1 / €1

*Read 5 free articles per month without a subscription

Join now for unlimited access

Try first month for just £1 / $1 / €1

Creative Bloq Staff

The Creative Bloq team is made up of a group of design fans, and has changed and evolved since Creative Bloq began back in 2012. The current website team consists of six full-time members of staff: Editor Kerrie Hughes, Deputy Editor Rosie Hilder, Deals Editor Beren Neale, Senior News Editor Daniel Piper, Digital Arts and Design Editor Ian Dean, and Staff Writer Amelia Bamsey, as well as a roster of freelancers from around the world. The 3D World and ImagineFX magazine teams also pitch in, ensuring that content from 3D World and ImagineFX is represented on Creative Bloq. 

Related articles