Alternate CP to resolve ISSUE-74 (also resolves ISSUE-105)

Hi folks,

below is the new draft of my image map Change Proposal minus the details,  
minus the test cases and before I have done some kinds of testing (most  
notably in IE) so minus the test results which would add to the rationale  
if they come out as I am told they do.

I'll try to update  
http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom with this  
content in the next hour or so, then I am going to work on test cases and  
on testing them.

cheers

chaals

Summary:

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.
7. Do not adopt the focus tracking parts of proposal Y.
8. Do maintain the caret tracking part of proposal Y.

Rationale:

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, including in some cases on the canvas element, so this  
proposal reduces the changes required. Browsers do not support the model  
currently in the working draft. (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 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 broader than 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, so is more  
useful that 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 proposal Y (8).

Details:

changes to be made in the canvas element, the map element, in attributes  
allowed on all elements... forthcoming.

Impact:

  positive:

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, and the concepts are generally familiar to developers  
already.
Removes the need for browsers to substantially change their existing image  
map code.

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:

Requires allowing some attributes on elements which were previously not  
allowed. Still requires authors to take some proactive steps to develop  
accessible applications.

  conformance 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).



-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Thursday, 10 June 2010 16:34:00 UTC