Working Group Decision on ISSUE-74 canvas-accessibility and ISSUE-105 canvas-usemap

Summary of Arguments

Regarding the nonav attribute

There were no claims or arguments about nonav that were actually contested. It seems that those who favor adding it and those who favor leaving it out agree that it does something useful, but that the functionality can be achieved in another way. No one who favored including it felt strongly - expressions of indifference were common. A few objected to including a redundant feature without a clear demonstration that the use case is very common.

Overall, it seems that the case for nonav is weak, and that there are no strong objections to leaving it out. The objections to adding it (i.e. that it is a redundant shorthand for a use case not shown to be common) are also fairly weak, but slightly stronger overall.

Regarding usemap support

Proponents of adding usemap support thought that it could be a handy convenience for some simple use cases of canvas. In general, however, advocates were lukewarm in their support, considering this a low-priority item relative to a full navigable DOM. The key questions in are whether image maps would make it easier to make canvas accessible in some cases, whether these use cases are common, and whether the greater simplicity outweighs the cost of adding a second model of canvas accessibility.

There was not much contention over the proposition that some use cases were made somewhat simpler with the usemap approach. The primary dispute was over whether these cases are common. It seems that the cases where image maps help significantly are primarily cases with active areas in a fixed layout, with relatively simple shapes and no complex overlap. Some examples were provided. One Web application in the wild seemed like it could make sufficient use of image maps. A constructed pie menu demo showed that it could work in practice for particular kinds of content. Thus, the objections on either side based on frequency of use cases seem weak on initial review. Little specific evidence was given for the objection to adding usemap based on not covering enough use cases; the claims were largely made in general terms. But on the other hand, the evidence that usemap can cover a broad range of canvas use cases was also weak.

Returning to the pie menu example, it is notable that by attempting to use dynamic content, the pie menu demo has a serious bug. It dynamically displays a pie menu, but the menu segments are visible and focusable even when the menu is hidden. This points to the other key issue - are use cases truly made a lot simpler by usemap? It seems that usemap is more concise in truly trivial cases, but it is very easy to go beyond the limits of what is simple, even accidentally. At that point, for correctness, usemap would have to be dropped for the full navigable DOM model, or significant additional complexity would have to be added to make use of usemap properly.

This additional information reinforces the objection that usemap does not cover enough use cases. One of the few examples presented was buggy, and seemed to show that it's easy to accidentally go beyond the narrow scope of what usemap can handle. Thus, the objection to adding usemap on the basis of not covering enough use cases turns out to be the stronger objection.

Regarding removal of accessible/navigable dom support in favor of usemap

Using image maps as the sole mechanism for canvas accessibility, and setting aside the navigable and accessible child DOM approach entirely, was a controversial proposal. Disagreement came down to a few key points: developer familiarity, generality, and implementation cost.

Some argued that the image map approach is more familiar to Web developers, from its use in client side image maps. However, image maps are not a commonly used feature on the Web today. Furthermore, the proposal suggests a number of changes to image maps to make them more complete. Others argue that the approach of using the full HTML language to construct an accessible alternative is more familiar to authors overall. Since familiarity arguments cut both ways, author familiary alone does not constitute a strong objection to either the the navigable DOM approach or the usemap-only approach.

The image map approach significantly extends image map functionality with the aim of seeking greater generality. However, it is argued that the functionality offered is still not as complete as the navigable DOM approach for advanced use cases. Study shows that there are indeed some things it cannot do, such as support custom focus ring appearance, overlapping active areas, and custom mouse interactions. Thus, the objection that the usemap approach, even with extensions, doesn't cover a wide enough range of use cases is relatively strong.

Finally, the usemap approach was promoted as something that would be easier to implement, since browsers already include support for image maps on the img element. However, the proposal also includes a number of novel image map extensions, and no argument was made that these extensions are also easy to implement. Further, at least one browser already has implemented support for the DOM-based canvas accessibility approach, while none have yet implemented image map based canvas accessibility. This is stronger evidence of implementability than a priori reasoning alone. Thus, the most prominent objection to the nonav model, that it raised more implementation difficulties, cannot be seen as a strong objection in light of the evidence.

On the whole, the objections to the usemap-only model were stronger. The objections in each direction based on author familiarity were about equal and so balanced out. The objection to the navigable DOM model based on perceived implementation difficulty was found to be weak. The objection to the usemap-only model on the basis of covering insufficient use cases was found to be relatively strong.

Decisions of the Working Group

Therefore, the HTML Working Group hereby makes the following decisions:

1. The nonav attribute will not be added to HTML5.
2. Image maps as an alternative to the navigable DOM will not be added to HTML5.
3. The navigable and accessible child DOM of the canvas element will be retained in HTML5, and will not be removed in favor of other techniques.