Re: Proposed Sub-Heading Text for Guideline 8

Jim,
Thanks for the comments.  The current discriptions that you commented on
were not designed to be checkpoints that user agents must implement.  Over
the past 18 months we have talked alot about different navigation
techniques and the following is an "abstrat" list of the different types of
navigation techniques we have discussed.  These strategies are designed to
provide developers with a context in which to think about different
navigation techniques.  Different strategies are better for different
people and different task contexts.  

>
>JRG: Sequential: Move sequentially between a set of element types based on
the
>linear order of the element(s).  This type of functionality is important
>for exploring the contents of a new document.  The user knows they will
>view all elements that are part of the sequential navigation.
>
>JWT: This is too abstract for me. I think the sequential navigation should
>require stepping through the document item at a time, with 'item' not
defined!

JRG: We have checkpoints which will identify particulatr items and we also
have a checkpoint that allows the user to select the items they want to
sequentially navigate to.

>
>JRG: Direct: Move directly between an element or a set of elements based
on the
>element content or numerical position of the element.  This type of
>functionality is important for faster access to web content when they know
>the location of the information of interest.  This often happens when the
>user is using a frequently visited document.
>
>JWT: I don't know understand what this means. And I worry, if all the
navigation
>methods were provided, a user could never find their way. It is easy to
say to
>navigate by many different methods, but it may be very difficult to
present all
>these hypothetical/academic methods to a user. For example if I take this
>literally I have to have some command structure that moves by element or
set of
>elements. T there are dozens of elements and two to the dozens sets of
elements.
>Do you mean, like HPR does, previous, current and next table, or header?  Are
>you suggesting such for all elements?

JRG: An exampel of this navigation technique is in lynx where you can bring
up a list of links and select one of them based on their numerical
position.  JAWS for Windows also has a direct technique for select a link
from a list of links using the first letter of the link content text.  This
strategy tries to abstract these specific methods.  

>
>JRG: Searching: Search for an element based on element content or attributes.
>All elements or only a sub set of elements maybe part of the search.  This
>function is important to users that are looking for particular key words or
>other type of web content to efficiently identify if the information is in
>the document and move to the element containing the information.
>
>JWT: Searching is one of the best strategies for navigation. But you make it
>close to impossible. You require searching content (text, like crtl+F in a
>browser but include attributes, and arbitrary restriction of search. This is
>left field. I know of no useful restriction of search. The only attribute I
>think is useful is alt-text. And it is important to move to forms, which,
with
>hpr, you do with a search for 'form.'

JRG: This is just describing the strategy of searching, there are actual
checkpoints for searching specific element content.  We also have a
checkpoint for configuration of searching.

>
>JRG: Hierarchical: Based on the document model tree move between the logical
>relationships between elements.  This type of navigation allows the user to
>efficiently move between logical units of the document.  This can be very
>useful for strongly structured documents like books or instructional
>materials.
>
>JWT: I wish someone would tell me what logical elements of CNN, NYTIMES or
IBM
>are! Again, I think this is left field for a realistic browsing strategy.

JRG: WIth poorly formed documents hierarchical navigation would not be very
useful, but if documents are well formed then this can be a very valuable
technique.  This is probably the most adavnced navigation technique since
it is heavily depedent on the author using structure in their document.  I
agree that all to often this doesn't happen.

>
>
>JWT: My bottom line is that your should encourage browser developers to
provide
>navigation strategies. Let the market determine the best strategies. I
have seen
>a couple of navigation strategies used by screen readers that we will use
in the
>next HPR. This is the way browsers should/will develop.  Please do not try to
>prescribe navigation. No one will listen, and such prescription will
lessen what
>you say in other areas.

JRG: The current checkpoints under guideline 8 are very general and we hope
will serve as a guide to developers.  Take a look at the current
checkpoints for the Guideline 8:

http://www.w3.org/WAI/UA/WAI-USERAGENT-19990716/#gl-navigation

If you have some interesting navigation techniques and would be willing to
share them, could you send them to the list.  We would really like to use
them in our techniques document.

Thanks again for your comments,
Jon


Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:	http://www.staff.uiuc.edu/~jongund
	http://www.als.uiuc.edu/InfoTechAccess

Received on Monday, 2 August 1999 15:35:39 UTC