- From: Charles McCathieNevile <charles@w3.org>
- Date: Wed, 15 Sep 1999 09:06:35 -0400 (EDT)
- To: Ted Wugofski <Ted.Wugofski@OTMP.com>
- cc: "'Ian Jacobs'" <ij@w3.org>, "'w3c-html-wg@w3.org'" <w3c-html-wg@w3.org>, "'steven.pemberton@cwi.nl'" <steven.pemberton@cwi.nl>, "'w3t-ui@w3.org'" <w3t-ui@w3.org>, "'dsr@w3.org'" <dsr@w3.org>, "'w3c-wai-gl@w3.org'" <w3c-wai-gl@w3.org>
Actually the question that Ted is adddressing is about different types of navigation bar. A navigation bar is a collection of links - which is exactly what MAP is for (or so it seems from reading the specification). Some of those are used once in an entire website, some are used fifteen times in a page. Charles McCN On Wed, 15 Sep 1999, Ted Wugofski wrote: I find this a very interesting proposal, but I am a bit concerned that it is making implicit things that ought to be explicit. For example, and I quote: % If user agents can suppose that MAP may be used % to identify navigation bars (or other navigation % mechanisms), they can offer navigation bar % hide/display functionality. This is very loaded. If a browser wants to assume that a MAP in a document is a navigation bar, does that mean that all MAPs in a document are navigation bars? Are there additional hints that a browser should use (such as the topmost or bottommost or ....) to narrow down the decision. Could there be a style (CSS) property so that navigation bars can be rendered differently on different browsers? As to the specific changes, they both seem reasonable. However, I am concerned that the premise behind these changes might be faulty. Perhaps we need to enrich the language with something that clearly denotes content which is a "navigation bar" from content that is not. Ted % -----Original Message----- % From: Ian Jacobs [mailto:ij@w3.org] % Sent: Friday, September 10, 1999 6:50 PM % To: w3c-html-wg@w3.org; steven.pemberton@cwi.nl % Cc: w3t-ui@w3.org; dsr@w3.org; w3c-wai-gl@w3.org % Subject: PROPOSAL FOR HTML 4.01: MAP used for navigation mechanisms. % % % Steven, % % The HTML 4.01 Proposed Recommendation [1] includes % some changes to the content model of the MAP element [2] % to allow mixing of block content and AREA elements: % % <!ELEMENT MAP - - ((%block;) | AREA)+ -- client-side image map --> % % This change was incorporated into HTML 4.0 [3] to allow authors % to create richer non-graphical alternatives to image maps. % The HTML 4.0 Recommendation used the wrong content model, % however, but HTML 4.01 corrects that mistake. % % In HTML 4.01, the following text describes the role of % the block content: % % <BLOCKQUOTE> % 2. Block-level content. This content should include % A elements that specify the geometric regions of the % image map and the link associated with each region. % Note that the user agent may render block-level % content of a MAP element. Authors should use this % method to create more accessible documents. % </BLOCKQUOTE> % % I am proposing two changes to the description of MAP, % again to promote accessibility. The goal of the proposal % is to make it easier for users of speech % synthesizers and users with motor impairments % to bypass navigation bars (groups of links). % These groups of links often appear first on a page % and are often repeated on many pages of a site. Often, % the users cited must wade through numerous links % before getting to important content on the page. % % If user agents can suppose that MAP may be used % to identify navigation bars (or other navigation % mechanisms), they can offer navigation bar % hide/display functionality. The HTML 4.01 specification % does not prohibit the use of MAP for general navigation % mechanisms, but this proposal will make it more obvious % that this is possible. % % The proposal involves two changes: % % Change 1) Change the second sentence of the above % quoted text to "User agents should % render block-level content of the MAP element." The % change is from "may render" to "should render". % % In a number of current browsers tested, block-level % content is rendered, so this change conforms to % current practice and will not break pages. % % Change 2) Change the first sentence of section 13.6.1's % description of the MAP element from: % % <BLOCKQUOTE> % The MAP element specifies a client-side % image map that may be associated with one or more % elements (IMG, OBJECT, or INPUT). % </BLOCKQUOTE> % % to: % % "The MAP element specifies a client-side % image map (or other navigation mechanism) % that may be associated with one or more % elements (IMG, OBJECT, or INPUT)." % % Note that HTML 4.01 does not require that a MAP % be associated with an image (IMG, OBJECT, or % INPUT elements). Thus, an author could use % MAP with a list of links as content and no % associated image to create a navigation bar. % % I realize that this proposal comes during the Proposed % Recommendation review period, but the changes would cost % little and would help the WAI Guidelines Working Groups % (Web Content, User Agent, Authoring Tool) who have been % wrestling with this issue for quite some time. It would % be a timely boon for the UA and AT Working Groups % in particular as they have documents nearing Proposed % Recommendation. % % Thank you for considering this proposal, % % - Ian % % % [1] http://www.w3.org/TR/1999/PR-html40-19990824 % [2] http://www.w3.org/TR/html40/struct/objects.html#h-13.6.1 % [3] http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.6.1 % % -- % Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs % Tel/Fax: +1 212 684-1814 % Cell: +1 917 450-8783 % % --Charles McCathieNevile mailto:charles@w3.org phone: +1 617 258 0992 http://www.w3.org/People/Charles W3C Web Accessibility Initiative http://www.w3.org/WAI MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA
Received on Wednesday, 15 September 1999 09:06:45 UTC