Re: Proposed Sub-Heading Text for Guideline 8

I apologize for commenting so infrequently. Your comments about browsing
prompted this response. I have indicated your writing with JRG, mine with JWT.

JRG: Guideline 8: Provide navigation mechanisms

JRG: Proposed Sub Head Text

JRG: Users need to be able to navigate the web content.  Speech and Braille
users especially need to have advanced navigation techniques, since speech
and dynamic Braille displays offer only a temporal or very limited view of
the document at one time.   Users need to be able navigate both active and
non-active elements using strategies that support the users current
familiarity of the document and the task they are trying to accomplish. The
following are four basic types of navigation strategies user agents need to
support:

JWT: I would call them refreshable braille displays. In both cases, speech and
braille, the limitation is the serial nature of the access, the inability to
"see" the broader picture and to be able to go where the author would really
like you to focus. This last statement is reason that there is hope for authors
to adopt a "skip to main content" idea. It is less the "size" of the window.
Anyway, the issue is not the size of the view. If, when I entered microsoft.com,
I could hit one command and be at the main content, that would be great, whether
or not I was listening, or had a 20 character braille display.

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: 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: 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: 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.


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.


Jim Thatcher

Received on Friday, 30 July 1999 22:10:01 UTC