- From: Charles McCathieNevile <charles@w3.org>
- Date: Tue, 13 Apr 1999 15:01:51 -0400 (EDT)
- To: Jan Richards <jan.richards@utoronto.ca>
- cc: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
first thoughts: In the context of a tool which produces a single page (eg via "save as xml") there will not usually be a site map, so the question does not arise. In the context of a tool which provides management of a number of pages, and the relationships between them, a site map may be part of the content it produces (so it is addressed in section 2) and may also be part of the information it presents to the author, so they know what the relationships in question are, (and can navigate via them or change them - covered by 3.3). In this context, the presentation of the site map to the author needs to be device-independent, and independent of the final published presentation of the website (use of the word "form here" would get confusing - it can mean the presentation, or the "shape of the thing in cyberspace, which is exactly what a site map represents"). So it seems to me to belong to 3.2.1. Certainly it seems to me that it is not a checkpoint, but a technique - the required checkpoint is, in my mind, 3.2.1 I think we already cover, in 3.1, the requirement that all the ways of getting around must be accessible. It may be worth explicitly mentioning that all parts of a tool are covered, but it seems redundant. charles McCN On Tue, 13 Apr 1999, Jan Richards wrote: You are right about 3.1 covering the issue of other suite tools generally, but I don't think 3.2 covers it because that guideline is more focussed towards flexibility of content presentation. A authoring tool site map is not really content in the way we have defined it. I think the intro to 3 should mention that these guidelines apply to all tools in the suite, then 3.4.2 should be placed as a technique in 3.1. General musing: the difference between (1) an authoring tool site map, (2) a site map placed as content in a document and (3) site displays by browser-OS hybrids could get very fuzzy depending on implementation details. Should we explicitly mention that all methods for navigating to and accessing documents for editing must be accessible? Charles wrote: > I think the issue is covered generally by guideline 3.1, and that the > specific issue of not relying on a given presentational method is covered > in 3.2. > So I favour it becoming a technique in one of those, preferably 3.2 > On Fri, 9 Apr 1999, Jan Richards wrote: > > If anything, this checkpoint should be a technique under a new > > checkpoint that addresses the need for access awareness in all the tools > > in a design suite. > > Charles wrote: > > > 3.4.2 P2 > > > I don't believe the last is a technique if it gets worded properly as we > > > discussed somewhere. Jan Richards jan.richards@utoronto.ca ATRC University of Toronto --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 Tuesday, 13 April 1999 15:03:02 UTC