Re: Sequential Navigation within a View

Thank you for your comments.

In their current form, the guidelines refer to two mechanisms, which are
used together to provide sequential navigation functionality within a view.
The first is described in section 6.1, "Sequential Navigation Within A View",
and the second in section 7.2, "Menu Commands", Item 1.

Our proposal combines the functionality of these two mechanisms, into one
generic sequential navigation mechanism. We believe that the strongest points
of the proposed approach lie with the simplicity and uniformity with which a
user will be able to navigate a document. Please note that this is independent

of the actual types of elements that the user will be allowed to navigate by.
This way the user will have to perform fewer interaction steps to navigate
among elements of the same type, having, furthermore, only one set of
navigation
commands to memorize (compare this, for example, to having to remember
different
keyboard commands to move to the next heading, previous form element, etc.)

Let us now move on to the issue of which elements should the user be allowed
to navigate by. The term "any elements" used in the initial proposal, was not
meant to imply that navigation by *every* HTML elements should be possible.
Rather, it was meant to refer to those elements in the rendered page that the
user can distinguish from the rest, and identify as having particular
characteristics.
In our view, the guidelines already assume that the user has a rather
good understanding of what a formatted text document is, as well as of the
functional and non-functional attributes of elements that may be encountered
within an HTML document.

The above is evident from the fact that the mechanism in section 6.1, allows
the user to sequentially visit links, form elements, images and image maps. A
direct implication of this is that the user knows what links, form elements,
frames, images and image maps are. In the opposite case, a truly novice and
inexperienced user will think that the browser arbitrarily scrolls to
different
parts of the document. Furthermore, by proposing the use of menus for header
navigation, the guidelines assume that the user knows what a header is. This
means that it is already assumed that the user comprehends at least part of
the
document's formatting.

Based on the above, the elements we believe the user should be at least
allowed
to navigate by are the following: links (including image map areas), elements
with
"longdesc", forms and form elements, tables,  lists and list items, elements
with
DHTML events, paragraphs, sentences, headers. All these are elements that the
user
can distinguish from the rest of the elements in a page, and identify them as
having
a particular property / functionality.

A second point you raised in your email concerns the employment of menus to
provide
an overview of the document. Although it is a very good idea to allow the user
to
get different overviews of the document, menus might not be the best approach
to
presenting them to the user. Menus excel when used to provide the user with an

overview of the functionality of an application and are rarely used when they
are
very long, not to mention when they entirely different (with the exception of
the
first few items) for every document the user visits. Imagine for example a
menu
containing the headers of a long research publication with descriptive section

headings. The menu would be hardly usable. Or, what about a menu containing
the
links in a "Links" page that is becoming a norm in almost all types of sites.
Presenting a limited list of the elements in the menu, as specified in Section

7.2, is a partial solution to the above problem, but introduces, in turn, a
new
problem, that of not allowing true "random" access to elements. If, for
example,
10 headers are included in the list, and there are 15 in the document, then
the
user will not be able to directly access the last 5 ones, which compromises
the
very usefulness of the current approach.

We believe that a far more usable and elegant solution for providing document
overviews and enabling "random" access to document elements, would be the use
of separate views, along with view synchronization, as specified in section
4.7 "Alternative Views of the Document", Item 1.

In summary, we propose that the navigation mechanism for sequential access to
different types of document elements should be harmonized and, even better,
unified across elements types. We further propose that overviews and "random"
access to document elements are achieved through separate, synchronized views
as already proposed by the guidelines, rather than through menus.

To better clarify the proposed approach I am including below the communication

with Bryan Campbell, in which specific examples of operation are included.
Comments and
suggestions are always more than welcome.

Best regards,

Napoleon



+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Hello Bryan,
Again I would like to apologize for taking such a long time to reply to your
mail.

Thanks for commenting on our proposal.

The number of keyboard commands the user needs to go through in order
to use the navigation mechanism we propose depends on the specific
choices developers will make in implementing the mechanism. Instead
of referring to key presses, therefore, please allow me to briefly
describe the idea in terms of "interaction steps". Naturally, the
ideal implementation would manage to allocate single (combined) key
presses to each interaction steps.

The enhancement to the navigation model we are proposing involves
two main tasks: (a) selection of the type of element (or elements, I
will explain this further below) by which the user will navigate the
document, and (b) navigation within the document itself, including,
but not necessarily limited to, the ability to move to the next
previous elements of the selected type in the document, as well as
the ability to move to the very first and very last such elements in
the document.

In terms of functionality one can distinguish between two variations
for task one. If navigation is limited to a single type of element at
any time (of course this does not include "normal" document navigation
whereby all elements are visited sequentially), then this is a task of
simply selecting an option among mutually exclusive alternatives. The
normative way of doing that would be through a menu (e.g. a menu
entitled "Navigate" and items such as "By Header", "By Paragraph",
"By Link", etc.) Very common, or frequently used options should of
course have keyboard shortcuts, making them accessible in a single
interaction step, from any point in the interface.

An alternative to the above would be for the user to be allowed to
select multiple types of elements to be visited during navigation.

One way to implement this would be through the use of a dialog, which
would present the user with a list of navigational elements and allow
him/her to selecting multiple types of elements to navigate by. In
this case, the implementation of the navigational mechanism requires
the following interaction "steps"
1) Open the dialog
2) "Next" and "Previous" commands, to scroll through the list of
   items
3) "Select" / "Unselect" command to add an element type to the
   current set of navigable elements
3) An "OK" and a "Cancel" command to close the dialog

The "OK" and "Cancel" commands above would be the standard "OK" and
"Cancel" keyboard commands used for all dialogs. The "Next" and
"Previous" commands could be the same keyboard commands used to
navigate between elements in the view.

Although this approach would significantly enhance the flexibility of
the navigation model, it would also be very demanding on the user,
imposing considerable load on short and long term memory, both in terms
of interaction, but also in terms of anticipated system behaviour (I could
elaborate on this if necessary). Furthermore, we don't believe that the
added flexibility outweighs the resulting increased complexity. Therefore,
we would prefer that only the former approach be included in the
guidelines.

In terms of interaction, the functionality of the second task (navigation
in the document itself) can be implemented using four "commands": Go-To-Next-
Element, Go-To-Previous-Element, Go-To-First-Element, and Go-To-Last-Element.
Of the four, only the first two (next and previous element) are of vital
importance. The latter two (first and last element) would be invaluable
though in long documents, especially ones of a known structure.

Attempting to address your question of how many keystrokes it would take to
make effective use of the proposed navigation model, I will go through a
very simple scenario (for the needs of the scenario I assumed that the
following correspondence between commands and keys exists: next element -
"Arrow-Down", previous element - "Arrow-Up", last element - "End", first
element - "Home"):

Assume you know that you want to select a link in a long document, but you
are not sure if it was the third from the end, or the second from the end
(note that the fact these is no other link between them does not imply that
these two are necessarily close to each other). Using the proposed approach
you would:
1) press "Alt-L" to switch to link navigation mode (assuming that because
   it is a very important mode it has its own shortcut)
2) press "End" to go to the last link in the document
3) press "Arrow-Up" to go to the second link from the end, review the link
   and possibly
4) press "Arrow-Up" again to go to the third link from the end

I would like to iterate that the rationale for proposing this modification
to the guidelines, is to ensure that the very good idea of supporting
alternative navigation models (modes) in the document, is supported in an
intuitive way, imposing as little interaction burden on the user as possible.
It is interesting to note that in most cases (I am tempted to say all but
perhaps I am missing some complex cases, so I will refrain from that) the
proposed approach is faster in terms of interaction steps and requires
fewer keyboard shortcuts than the one currently included in the guidelines.

We would be very interested to find out what you and other people on the
list think, especially after the above, more detailed description.

Best regards,

Napoleon


Napoleon Maou
Software Engineer
AT&HCI Laboratory
ICS-FORTH
voice : +3081391742
email : maou@ics.forth.gr
WWW   : www.ics.forth.gr




Jon Gunderson wrote:

> Your approach I think may work for an experienced user who understands
> tags.  But what about the niave user who won't know want to look for or
> situations where a user just wants to get an overview of the document with
> out having to read every element.
> Jon
>
> At 09:17 PM 7/31/98 +0300, maou wrote:
> >Hello,
> >My name is Napoleon Maou and I am a staff member at the Assistive
> >Technology and Human computer Interaction (AT&HCI) laboratory , at the
> >Foundation of Research and Technology Hellas (FORTH).
> >
> >I am interested in technologies that will make the Web, or any other
> >information system, accessible to people with disabilities.
> >At FORTH I have participated in the development of the AVANTI unified
> >browser, a browser that in addition to motor abled users, is accessible
> >by blind and motor impaired users.
> >
> >I would like to comment on the subject of sequential navigation within a
> >View.
> >
> >I believe that there should be only one generalized mechanism to
> >navigate elements within a view. Section 6.1 talks about a mechanism for
> >sequential navigation of links, form elements and elements with
> >longdesc( using keyboard commands ) , and section 7.2 talks about
> >another mechanism that can be used for sequential navigation of Headers
> >or other elements ( using menus and menu shortcuts ).
> >
> >The problems I see with the existence of two mechanisms are the
> >following
> >1)  There exist more than one keyboard commands or menu keyboard
> >shortcuts, which have essentially the same meaning. "Move to next item".
> >For example if we have menu items to navigate Headers and Paragraphs
> >then there will be a "Next Header", a "Next Paragraph" and a "Next
> >link/longdesc/form element" command.
> >2)  If the user wants to navigate Headers and paragraphs then the
> >current mechanisms does not allow him to do that. He can navigate
> >Headers or Paragraphs but not both at the same time.
> >3)  For people with motor disabilities using menus to navigate will be
> >very time consuming.
> >4)  For blind people there is the problem of having to memorize more
> >keyboard commands than are needed.
> >
> >Proposed Mechanism
> >---------------------------
> >I believe that the UA should provide to the user a simple generalized
> >mechanism to navigate any elements in the view. This mechanism should:
> >a)  Allow the user to select the elements he wants to navigate.
> >b)  Provide  commands to move among the elements of the view.
> >
> >A mechanism like that I believe will be easy to use and is general
> >enough to allow the user to navigate any element combinations.
> >
> >Napoleon Maou
> >
> >--
> >Napoleon Maou
> >Software Engineer
> >AT&HCI Laboratory
> >ICS-FORTH
> >voice : +3081391742
> >email : maou@ics.forth.gr
> >WWW   : www.ics.forth.gr
> >
> 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



--
Napoleon Maou
Software Engineer
AT&HCI Laboratory
ICS-FORTH
voice : +3081391742
email : maou@ics.forth.gr
WWW   : www.ics.forth.gr

Received on Friday, 14 August 1998 07:51:46 UTC