- From: Steven Pemberton <Steven.Pemberton@cwi.nl>
- Date: Thu, 23 Sep 1999 10:15:26 +0200
- To: "Ian Jacobs" <ij@w3.org>, <w3c-html-wg@w3.org>
- Cc: <w3t-ui@w3.org>, <dsr@w3.org>, <w3c-wai-gl@w3.org>
Ian, The HTML WG agreed to this change yesterday at their telephone conference call. Best wishes, Steven ----- Original Message ----- From: Ian Jacobs <ij@w3.org> To: <w3c-html-wg@w3.org>; <steven.pemberton@cwi.nl> Cc: <w3t-ui@w3.org>; <dsr@w3.org>; <w3c-wai-gl@w3.org> Sent: Saturday, September 11, 1999 1:50 AM 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 Thursday, 23 September 1999 04:15:14 UTC