- From: Jon Gunderson <jongund@staff.uiuc.edu>
- Date: Mon, 02 Aug 1999 14:40:29 -0700
- To: thatch@us.ibm.com
- Cc: w3c-wai-ua@w3.org, ij@w3.org
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