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

Questions before the Working Group

The current HTML5 draft includes support for canvas accessibility in the form of a subdom, which is not rendered but remains active and exposed to assistive technologies. A number of proposals have been made to change or augment this support in various ways. Thus, the following questions are before the working group:

  1. Should a boolean nonav attribute be added to the canvas to hide its contents from assistive technologies and keyboard navigation?
  2. Should image map / usemap support be added as a possible way to represent focusable regions on the canvas?
  3. Should the ability to use the children of canvas as an accessible dom entirely, in favor of other techniques, such as usemap?

This scope of this decision covers accessibility mechanisms to expose canvas contents to assistive technologies. It does not include mechanisms specific to text editing, such as focus, caret, and selection; those will be covered by ISSUE-131 caret-location-API. A section below details what arguments were not considered, some of which were not considered due to scope reasons.

Originally, a fourth question was included, regarding advisory text warning against the use of canvas for text editing, and giving advice on how to handle caret and focus with existing APIs. The Chairs have decided to defer consideration of this question, since it fits more naturally with ISSUE-131. All comments submitted will be considered as part of ISSUE-131.

Uncontested observations

Regarding the nonav attribute

Regarding usemap support

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

These claims were not decisive by themselves. There were people who supported either of these proposals even after taking these facts into consideration.

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.

Next Steps

Since the Change Proposals calling for spec changes did not prevail, no no further actions are required. The bugs relating to issues 74 and 105 will be marked as WGDecision.

Appealing these Decisions

If anyone strongly disagrees with the content of the decisions and would like to raise a Formal Objection, they may do so at this time. Formal Objections are reviewed by the Director in consultation with the Team. Ordinarily, Formal Objections are only reviewed as part of a transition request.

Revisiting these Issues

These issues can be reopened if new information come up. Examples of possible relevant new information include:

Additionally, as APIs specific to text editing were not considered to be within scope of this issue, concrete suggestions for editing-specific APIs can be considered as part of ISSUE-131.

Arguments not considered

Arguments relating to focus, selection and caret management, and other text editing related issues, were not considered. These topics are out of scope for this survey and will be covered under ISSUE-131.