RE: Structure navigation within a document, re: Development Cost

It's easy to come up with rationales after the fact and find all sorts of
neat uses of the proposed feature.  However, the solution did not grow out
of a real need.

Each item I mentioned can be dissected individually, but when combined show
the relative lack of importance/benefit of the proposed feature.  Also,
there is no discussion of possible alternative solutions and how it might
compare with the existing checkpoint.

I'm trying to show that the process for developing checkpoints is flawed,
not to eliminate this or any other existing checkpoint.  All ideas are
valid.  If someone says they need a structure view of the document, web
site, Intranet, or the Universe, that's fine with me.  Tell me why you need
it (i.e.: what problem are you currently having that this feature solves)
and then let's brainstorm on this feature and some other ways of solving the
problem.  All those solutions should go into the document.

-----Original Message-----
From: Charles McCathieNevile [mailto:charles@w3.org]
Sent: Tuesday, March 09, 1999 6:12 PM
To: Charles Oppermann
Cc: WAI AU Guidelines
Subject: Structure navigation within a document, re: Development Cost


These comments, and therefore my responses, seem only to address the case
of navigiation within a single document, not of navigating a series of
related documents.
On Tue, 9 Mar 1999, Charles Oppermann wrote:
[snip]  
  * It only helps document creators and editors, not users of the finished
web
  site
CMN:
This is true. One of the two goals of the group is to describe how to do
just that. It is in the context of what is necessary to help creators and
editors of the documents that the priority of this particular feature
should be assessed.

CO:
  * It only helps those document editors using speech output.  It is of
little
  help to users with mobility impairments or low vision people using screen
  magnifiers.  

CMN:
Actually the ability to navigate a structured tree, rather than having to
work through a document in its complete form, is of specific benefit to
people who have mobility impairments, for precisely the same reason - it
enables the document to be traversed with much less work. In the case of
magnified screens (and users with various types of cognitive disability)
it is the ability to work with an overview of a document

CO:
  * The degree that it helps those users is unknown and debatable
CMN:
While we could debate at great length the precise degree to which it
helps, and while I expect in the course of our work on these guidelines to
debate this and to refine our understanding, it seems that there is
clearly value to accessibility. We have heard, as we could also deduce
from a little thought, that the value is related to the complexity of the
material produced. About which more after
CO:
  * It's only meaningful in the cases where structure is important.  The
  feature would make little sense in products such as Microsoft Access,
Excel
  or Project.
  * The feature already exists in Microsoft Word.  Does it need to be
  duplicated in FrontPage?
CMN:
Essentially, that depends on whether Microsoft regards Frontpage as a tool
suitable for creating a structured document, or really only worth using
for trivial pages. (Whether resources are available to justify its
inclusion in these tools is a separate issue to whether there is a reason
to put it there in the first place).

Received on Wednesday, 10 March 1999 12:14:30 UTC