- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Tue, 10 Apr 2001 10:25:34 -0500
- To: Charles McCathieNevile <charles@w3.org>
- Cc: Ian Jacobs <ij@w3.org>, w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org
- Message-ID: <OF556BEF4A.401CEA46-ON86256A2A.0053EC38@raleigh.ibm.com>
It may not as easy as you might think. You need to make sure you can print the whole document from start to finish without duplicating sections and you need to make sure you cross link well with the techniques document. We broke up the IBM Java accessibility guidelines up because they were large and users want to be able to print from the main page the entire document whether you broke them up or not. In Windows we did this by printing all linked documents and having the main page include a table of contents (see www.ibm.com/able/snsjavag.html). Other OS's may not have this feature in their browser: (Embedded image moved to file: pic06694.pcx) Ian, while this may be nice I don't want to delay its release any longer because of editorial changes like this. Rich Rich Schwerdtfeger Senior Technical Staff Member IBM Accessibility Center Research Division EMail/web: schwer@us.ibm.com "Two roads diverged in a wood, and I - I took the one less traveled by, and that has made all the difference.", Frost Charles McCathieNevile To: Ian Jacobs <ij@w3.org> <charles@w3.org cc: <w3c-wai-ua@w3.org> > Subject: Re: Split UAAG 1.0 and Techniques into smaller documents? Sent by: w3c-wai-ua-requ est@w3.org 04/10/2001 06:24 AM Actually I think it is a fine idea. I agree that it isn't a high priority, but I suspect itonly takes a few minutes to do. Chaals On Mon, 9 Apr 2001, Ian Jacobs wrote: Hi folks, I probably shouldn't do this, but I am curious to know whether people think we should break UAAG 1.0 and the Techniques documents into smaller chunks. UAAG 1.0 (not including the appendixes) is 322k. The Techniques Document is 533k. These are both on the long side. It would be possible (though I haven't tried it yet to see what kind of effort is required) to split the document(s) into smaller pieces. We would also provide a link at the top to a single source HTML version (essentially, what people get today). The W3C Process Document [1] has been organized this way. Essentially, you only get the table of contents on the first page (in the Process Document case, that's only 18k). In the UAAG 1.0 case, it makes sense to split the document into the following pieces: a) Front page b) Introduction c) Guidelines d) Conformance e) Glossary f) References g) Acknowledgments For instance, the Guidelines section (the longest) would only be approximately 162k. The appendixes (checklists and summary) would still have their own URIs (but are considered part of the document package). The navigation mechanisms of the Process Document are pretty straightforward: you have next/previous/contents links at the top of each section. Obviously, this doesn't change the substance of the document, but it may be worth exploring. Your comments welcome, - Ian [1] http://www.w3.org/Consortium/Process-20010208/ -- Charles McCathieNevile http://www.w3.org/People/Charles phone: +61 409 134 136 W3C Web Accessibility Initiative http://www.w3.org/WAI fax: +1 617 258 5999 Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)
Attachments
- application/octet-stream attachment: pic06694.pcx
Received on Tuesday, 10 April 2001 11:26:19 UTC