From HTML WG Wiki
Jump to: navigation, search

Improve image maps and use them to make canvas accessible


Note that in principle it is possible to separate this proposal into several sub-proposals, and only adopt some of them. However the proposal as written is to adopt all of the suggested changes, to achieve maximum benefit at minimal cost.

  1. Allow usemap attribute on canvas (this would also resolve ISSUE-105)
  2. Revert the image map model to that of HTML 4.01 (allowing mixed block content and area elements)
  3. Allow shape and coords attributes on any element, associating them with a parent map element
  4. Introduce a value "path" for the shape element, which requires the coords element to be interpreted following the rules for the SVG path micro-syntax.
  5. When the canvas element is supported, make the content of the canvas element not navigable, except if it is an image map (as for maps inside object element, in HTML 4)
  6. Do not adopt the nonav attribute proposed in ChangeProposals/canvasaccessibilitynonav
  7. Do not adopt the focus tracking parts of ChangeProposals/canvasaccessibility.
  8. Do maintain the caret tracking part of ChangeProposals/canvasaccessibility.


(numbers after each point refer to which members of the itemised list in the summary address the point)

Developers and authors are used to image maps, and understand them already, including (to some extent) making them accessible. Allowing them to build on this knowledge to make canvas-based applications accessible will increase the likelihood of them doing so successfully. (1, 2, 3)

Browsers already implement image maps according to the HTML 4 or 4.01 specification, so this proposal reduces the changes required. (1, 2)

Browser implementation of accessibility in image map is relatively mature, so it is unlikely they will have major conceptual problems implementing this correctly. (1, 2, 3)

HTML 4.x image maps only allow for simple link elements (a and area) to be linked to a region in the display. Allowing other elements to do so will make it easier to match the range of elements which are now used to provide interactivity in Web applications. This matches and extends new capabilities offered by the current HTML5 draft. (3)

The range of shapes authors can paint to the canvas is different to those currently allowed by image maps. Precisely matching active regions on the canvas to the visual presentation, rather than having jagged overlaps, improves the user experience and will help author adoption. The SVG path micro-syntax is widely and interoperably implemented and used in browsers, so is more useful than introducing a new microsyntax. (4)

If fallback content is not navigable by default, authors can include it for browsers which do not support canvas without testing for that support and dynamically constructing different DOMs. This will simplify authoring where the fallback content for browsers without canvas support is different from the "accessibility content" for browsers that support canvas. (5)

While both proposals can successfully provide accessible canvas applications, having one method for doing so will make it easier to specify, explain, and implement both for browsers and for authors (5, 6, 7)

Visual focus tracking should be implemented by the user agent and chosen by the user, rather than being implemented by the author. This already happens for image maps (1, 7)

This proposal does not address the issue of caret tracking, although that is important and is adequately addressed in ChangeProposals/canvasaccessibility (8).

Test cases and results still to be added.


Change details - note that all references are according to revision 1.4098

For point 1 (add image map functionality to canvas):

Note: This proposal is essentially a copy of the proposal ChangeProposals/addimagemaptocanvas, but slightly more detailed to help the editor understand what is required to implement it.

In Section 4.8.10 the canvas element

Add the usemap attribute to the list of attributes for the canvas element


          attribute DOMString useMap;

to the interface description.


The usemap attribute, if present while the canvas element represents embedded content, indicates that the canvas has an associated image map.

to the description of the element.

In section 4.8.11 The map element

Change the following text:

The images attribute must return an HTMLCollection rooted at the Document node, whose filter matches only img and object elements that are associated with this map element according to the image map processing model.


The images attribute must return an HTMLCollection rooted at the Document node, whose filter matches only canvas, img and object elements that are associated with this map element according to the image map processing model.

(and adjust non-normative text and examples analagously).

In section 4.8.12 The area element

change the text

The area element represents either a hyperlink with some text and a corresponding area on an image map, or a dead area on an image map.


The area element represents either a hyperlink with some text and a corresponding area on an image map, an interactive region of an image map, or a dead area on an image map.

remove the text

If the area element has no href attribute, then the area represented by the element cannot be selected, and the alt attribute must be omitted.

Rationale: An area element may be used represent an aria region, or some other command element, without having an href attribute.

For point 2 (restore HTML 4.01 model), and point 3 (extend elements which can have shape/coords):

In section 4.8.11 The map element

Change the text

The map element, in conjunction with any area element descendants, defines an image map. The element represents its children.


The map element, in conjunction with all its element descendants that have a shape and/or coords attribute, defines an image map. The element represents its children.

and change

The areas attribute must return an HTMLCollection rooted at the map element, whose filter matches only area elements.


The areas attribute must return an HTMLCollection rooted at the map element, whose filter matches only elements which have either a shape attribute, a coords attribute, or both.

For point 3:

In section 3.2.2 Elements in the DOM


         attribute DOMstring shape
         attribute DOMstring coords

(Most logically in the user interaction block, but it is really an editorial issue)

In section 3.2.3 Global attributes

add shape and coords to the list of global attributes.

Add a reference to the existing definition of these attributes in section 4.8.12 the area element

In section 4.8.12 the area element


          attribute DOMString coords;
          attribute DOMString shape;

from the DOM interface section, and remove the shape and coords attributes from attributes specified for the area element.


While in principle there is no need to add shape to some elements (e.g. the title element) it is simpler to simply allow it everywhere than list the few exception. This is following the existing spec which allows event handlers and attributes such as tabindex on all elements.

Make the definition of shape and coordinates attributes a separate section (this is an editorial process, but I shall assume for the sake of this proposal that it is done by adding a section 4.8.12bis The shape and coords attributes which begins after the current text "In both cases, the shape and coords attributes specify the area." and includes all the content up to the beginning of section 4.8.13 Image maps).

In the putative section 4.8.12bis and in section 4.8.13 Image maps replace all references to area elements with references to "interactive map regions".

For point 4 (add capability for more complex paths to be used):

In the putative section 4.8.12bis The shape and coords attributes

Add to the table of allowable shapes the state "Path state" with the associated keyword "path".

Define the Path state (following the definition of the Rectangle, Default, Circle and Polygon states) such that the coords attribute represents a path according the the microsyntax defined in SVG for the d attribute of the path element, where the coordinate space is defined in CSS pixels with the origin at the top-left corner of the canvas and a y-down orientation. This could be done by copying in the text, with an informative reference to the source, or by making a normative reference to the SVG 1.2 Tiny specification. @@error handling should be the same as what SVG does.

For point 5 (fallback content not normally navigable):

In section 4.8.13 image maps

Add text saying the user agent has to allow the user to navigate active elements in an image map even when they are inside another element which blocks rendering (e.g. object, canvas)

In section 4.8.10 the canvas element

remove the text

When a canvas element represents embedded content, the user can still focus descendants of the canvas element (in the fallback content). This allows authors to make an interactive canvas keyboard-focusable: authors should have a one-to-one mapping of interactive regions to focusable elements in the fallback content.

For points 6 and 7 (don't use nonav attribute nor the focus tracking part of the alternative proposals):

Do nothing.

For point 8 (adopt caret navigation from the alternate proposals):

Keep the caret navigation part of the accessibility TF proposal (or some suitable alternative).

Example of use

Assuming a script that puts things on the canvas, can react to them being selected, and can update the DOM of the map to match any changes tothe painted canvas (e.g. by changing coords attributes as an interactive point moves around)

 <canvas width="300" height="400" usemap="#myMap">
  <map id="myMap">

    <label for="one">option one
     <input type="checkbox" shape="path" name="one"
      coords="M 20 50 c -20 20 60 20 50 0
       c -20 -20 0 -40 0 -40 c -20 -20 -20 20 -50 0 z">

    <img role="checkbox" shape="rect" id="two"
     src="squiggle.png" alt="option two" tabindex="0"
     coords="20 150 70 180">

    <area role="checkbox" alt="option 3" shape="circle"
     coords="50 200 50">



This is reinstating some aspects of the HTML 4.01 specification of image maps and allowing the use of canvas on images.

It reinstates the need for browsers to implement HTML 4.01 image maps (where they have not yet done it - many have partially done so, some completely). It also requires that image maps be usable with canvas.

It removes the need to change image maps, and the corresponding need to change advice given to authors and authoring tool developers.

Positive Effects

Takes advantage of existing browser implementation to provide built-in accessibility for certain types of application.

Simplifies the task of explaining how to make canvas accessible. Less coding is needed from authors to manage interactivity, and the concepts are generally familiar to developers already.

Removes the need for browsers to substantially change their existing image map code, thereby reducing implementation required compared to the current specification.

Allows authors to use image maps rather than pure javascript event listeners in order to make canvas interactive, which will simplify the development of certain classes of canvas-based application.

The proposal is effectively backwards compatible with existing browser behaviour, although not all benefits will be realised, and in some cases some hacking will be required (e.g. where shape="path" is not supported authors will need to use a second element which uses one of the older shapes, and where the shape/coords attributes are not supported on arbitrary elements authors may need to add redundant area elements for complete backwards compatibility).

Negative Effects

Requires allowing some attributes on elements which were previously not allowed which will require browser implementation to work.

Still requires authors to take some proactive steps to develop accessible applications.

Conformance Classes Changes

All image maps conforming to HTML 4 or HTML 4.01 requirements would conform to HTML5 (which they do not according to the current draft). Thus content generating tools will no longer produce invalid HTML5 if they change nothing.

Tools generating canvas *should* offer facility to produce new markup for accessibility, but this is probably a matter for ATAG techniques rather than HTML5.

A new requirement will be added for user agents.