- From: Charles McCathieNevile <chaals@opera.com>
- Date: Thu, 10 Jun 2010 18:33:23 +0200
- To: "HTML Accessibility Task Force" <public-html-a11y@w3.org>
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