W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 1999

RE: PROPOSAL FOR HTML 4.01: MAP used for navigation mechanisms.

From: Ted Wugofski <Ted.Wugofski@OTMP.com>
Date: Wed, 15 Sep 1999 07:53:56 -0500
Message-ID: <c=US%a=_%p=OTMP%l=MOON1-990915125356Z-42@moon1.otmp.com>
To: "'Ian Jacobs'" <ij@w3.org>, "'w3c-html-wg@w3.org'" <w3c-html-wg@w3.org>, "'steven.pemberton@cwi.nl'" <steven.pemberton@cwi.nl>
Cc: "'w3t-ui@w3.org'" <w3t-ui@w3.org>, "'dsr@w3.org'" <dsr@w3.org>, "'w3c-wai-gl@w3.org'" <w3c-wai-gl@w3.org>
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
%  
%  
Received on Wednesday, 15 September 1999 08:55:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:00 GMT