W3C home > Mailing lists > Public > w3c-wai-au@w3.org > January to March 1999

Re: structure view is not solely a navigation tool

From: Charles McCathieNevile <charles@w3.org>
Date: Tue, 9 Mar 1999 15:01:18 -0500 (EST)
To: "gregory j. rosmaita" <oedipus@hicom.net>
cc: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
Message-ID: <Pine.LNX.4.04.9903082150020.8715-100000@tux.w3.org>
I think  we are talking about two different types of structure.

The first is the internal structure of a document - in HTML this is
partailly expressed by the DOM tree and partially by the semantics of HTML
itself, such as the various levels of headings. In quality XML (and I
would like to imagine that authoring tools will not be producing
second-rate XML) it is likely that the DOM tree will be closer to the
semantics, in general. This is similar to the Table of Contents view and
the structure view provided by Amaya, the Outline feature of MSWord, or
the tree structure used by many file manipulation programs (dating back as
far as Unix, to my own knowledge). Navigation and manipulation by this
tree provides a great improvement in accessibility of the document to
users of devices which are inherently slower than large visual displays,
as well as to authors of large documents, or people with various cognitive
disabilities.

The second is the ability to navigate a series of documents. This is not
required where there is only a single document being edited, but is
important where, for example, a whole site is being manipulated. To give
some examples: An object-oriented authoring system for a graphically
represented 3 dimensional space might describe in text the layout of the
space, and the spatial relationships between each of the objects, or
between objects which are in "line of site" from each other; a database
might provide a tabular view of the database, another table of the fields
within the database and field-specific information such as the name and
type of data, with similar tables created (where appropriate dynamically)
for queries which can be made by somebody reading this database via the
web; A site map might be a list of the various pages, grouped into
sections, with information about pages to which those pages are linked;
A single page saying "hello world" would be a trivial case where there are
no structures to specify.

In each case, there is a significant accessibility gain in being able to
navigate the structures and edit at any point reached (or edit the
structures themselves). In each case the problems have been solved by
some tools, and left unsolved by others. Therfore it seems that each case
merits a checkpoint. It may be that such checkpoints are made redundant by
documents to which we refer already, but given Chuck Oppermann's
difficulties in understanding how such things might be implemented it may
not be the case. I therefore suggest we put them in, although they would
naturally be removed in subsequent review of the document if it could be
clearly explained how they are redundant.

The priority of the checkpoints is a seperate issue. In the first case I
would argue, along the lines of the current scheme, for a P2, although if
we moved to required or recommended then I would argue for required, since
in the case of non-trivial documents the accessibility of authoring the
document is significantly decreased.

In the second case I would argue for a P2, and for upgrading the
requirement for accessible 'site maps' to P1, but making it conditional on
'site maps' being provided anyway, expanding the meaning of a site map to
that which I have just outlined. (this is in relation to a map provided
for authoring - publishing an accessible site map has been covered in
section 2.

I'm not sure that this is ready to be a proposal yet. Anybody want to toss
it around some more?

Charles

On Mon, 8 Mar 1999, gregory j. rosmaita wrote:

  aloha, all!
  
  while charles and jutta have expressed the view that a structure view is a
  good idea, they have both opined that it fits into navigation....  as a
  totally blind page author, however, i find this too restrictive a
  distinction...  while i agree with jutta and charles that it fits into the
  navigation section, i also agree with will that it is an integral part of
  checkpoint 3.1
  
  why?  web sites (at least those that are worth their weight in bytes) are
  not built in isolation--the author must be able not only be able to
  navigate a structured view, but be able to interact with the structure
  view, which means editing one portion of the site whilst reviewing the
  site as a whole...  otherwise, i fear that, when authors such as myself do
  make the move to an authoring tool, we will be forced to edit/author pages
  in isolation...
  
  gregory.
  
    ------------------------------------------------------------------
                  Gregory J. Rosmaita <oedipus@hicom.net>
    Camera Obscura:           http://www.hicom.net/~oedipus/index.html
    VICUG NYC:          http://www.hicom.net/~oedipus/vicug/index.html
    Read 'Em & Speak:   http://www.hicom.net/~oedipus/books/index.html
    ------------------------------------------------------------------
  
  

--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, 9 March 1999 15:01:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 22 September 2008 15:52:54 GMT