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)