By Steve Fulton

While searching for the  updated W3C HTML 2d Context (Canvas) API Specification today I ran into some some references to a  new feature the W3C has proposed to add the Canvas Spec: Hit Testing .

It has been known for quite some time that the HTML5 Canvas, by it’s nature if being an Immediate Mode  bit-mapped area of the screen, does not lend itself to Accessibility.   There is no DOM or display list inherent in the Canvas to make is easy for accessibility devices (e.g. screen readers) to search for text and images and their properties.   To make the Canvas accessible, a method known as “Fallback DOM Concept” or “subdom” was devised.  Using this method, developers  create a DOM element that match every element on the Canvas and put them in the “subdom”, This method quickly becomes unwieldy for anyone who has tried to do anything more intricate than a simple Canvas interface.  Why? Because associating fallback elements with Canvas interaction is not always an easy task, and is complicated by screen readers that need to know the exact position of an element on the Canvas so they can interpret it’s properties.

Hit Testing Proposal

To help solve this issue, the Canvas needs some way to associate “subdom” elements with an area on the bit-mapped Canvas. The new  W3c Canvas Hit Testing proposal  outlines why this type of functionality should be added to the Canvas specification:

In the current HTML5 specification, authors are advised to create a fallback DOM under the canvas element to enable screen readers to interact with canvas user interfaces. The size and position of those elements are not defined, which causes problems for accessibility tools – what size/position should they report for these elements?

Because canvas elements usually respond to user input, it seems prudent to solve the hit testing and accessibility issues with the same mechanism.

So what kind of mechanism are they suggesting?

The idea is to create two new methods, setElementPath(element), and clearElementPath(element) that will allow programmers to define (and delete) an area of the Canvas to use as a hit area, provided that it is associated with an element the “fallback DOM” of the Canvas. It appears that you must have an accessible fallback DOM element to provide to setElementPath() in order to associate it for the hit detection.   When a hit is detected, an event is fired,  and all is right in the world.

So what does this mean for game developers?

Well, for user interfaces with stationary interfaces, it will make things a lot easier.  How many times have you wanted to create a simple way to click buttons on a game interface, but had to use the same hit detection routines you wrote for your in-game sprite interactions?  For us? Every time.   For moving sprites in your game though, it might be less useful.    You will have to update the setElementPath() and the fallback DOM element with new coordinate data every time something moves which means triple overhead for game that is probably not accessible in the first place.

Still, this is a good move by the W3C, as making the Canvas accessible for user interfaces is another a huge step in making it more widely accepted for web applications.  We hope these two new methods are added to the specification as soon as possible.