RE: navigating Vs searching

Navigation Styles: Does Separating Content from Presentation include
Navigation?

In pwWebspeak 1, we originally provided just direct navigation keys (e.g., H
to move to headers, P to paragraphs, etc.). In later releases we updated the
browser command set to allow definition of parameter driven searches to
provide more navigation options:

find-next-element (target-tagname)
find-prev-element (target-tagname)

find-next-text (target-text-size)
find-prev-text (target-text-size)

Using this facility, a user can customise the keyboard commands, creating
their own navigation key set for the browser.

We have expanded this to include the class value, and the basic approach
supports XML nicely.

This flexibility can lead to either a very large keyboard command set,
accomodating many different pages, or invites a more generalised solution
that can keep the navigation model simple, but adaptible to meet the needs
of different page styles or structures.

In navigating documents (which is where we spend a lot of our time in the
digital book world, but not to the exclusion of those pages which are
basically like host OS dialogs), we have been considering the idea of a
"navigation sheet". Rather than defining a single navigation key set (which
is what we do now by default), the UA can dynamically reassign the
navigation search targets based on the loaded documents' structure
(structure being loosely used with HTML).

As a UA, we can of course attempt to do this from the H1 .. H6, if present,
or directly from the XML structure, but we have no notion of the author's
intent. Realistically, we see XML as the far richer approach to provide
structure, but without some additional author supplied information, we can't
determine what are significant structural elements or even how they should
be identified.

For example, in the NY Times web site, "XML" mark up provides semantic
wrappers around text (e.g., NYT_SUMMARY, NYT_HEADLINE) and I've defined keys
to allow a webspeak user to easily navigate around that page, but we could
not have done this automatically with the mix of HTML and XML markup
present. At least we can allow the user to adapt his or her audio style
sheet to vocalise NYT_HEADLINE as "Headline", once they learn that this is a
significant tag, and add keys to navigate to it.

At a minimum, we (PW) are looking at providing something on the order
user-definable "navigation sheets" that can be associated by the UA with a
given page, providing a way to adapt the keyboard on the fly.  I think a
more generalised long term solution is the idea of "NavCSS" extensions to
CSS which might include a "level" and "role" style.  Mixing ACSS and with
NavCSS (which is what our webspeak styles do), we might end up with
something like:

NYT_HEADLINE {nav-level: 1; role:"News Headline"; cue-before:
url("tonesweep.wav")}
NYT_SUMMARY {nav-level: 2; role:"Summary"}

In well formed XML documents, nesting level can be used to determine levels,
but this is practically impossible in HTML, and in both cases author intent
with respect to the navigation significance of any element is unknown.
Nav-level provides an indication of the element's significance for
navigation. We have been using a version of Nav-level in the webspeak style
sheet since version 1; it is used to indicate whether a given tag is a
navigable element, and also includes information on how tags "fold"
together.

Role provides a way of "naming" the elements. A user agent (or assistive
technology) can enumerate the elements on the page and, for example,
announce "There are 6 headlines on this page. Press F8 to move to the next
headline and F7 to move to the previous headline."

To address the issue of changing keys from page to page, and completely
confusing the user, we (speaking for pwWebSpeak) would implement a set of
standard "prev/next item in a level" functions. Though the name of the top
level navigation element may change, (Heading in one case, Headline in
another), the same keystrokes would be used to navigate across top level
elements across pages.

I also wonder whether a NavCSS approach provides a mechanism to clear up
what some of us see as problems with ACCESSKEY. When we look at things like
voice browsing/tv-web/small device UA's, I think moving the ACCESSKEY
concept into a stylesheet makes sense.

The idea of cascading the AccessKey definition can take into account the
specific requirements of the user agent or host operating environment. The
idea of auto-numbering "accesskeys" for telephone browsing is one obvious
use. Pre-fixing the Accesskey for visual or auditory presentation with ALT
for Windows, OPTION for Mac, or something specific for a given accessibility
aid is also possible.

Comments?

Mark





> I think the type of searching Al is talking about is very useful in the
> case you know what you are looking for.  But, we also want to
> help user who
> are just trying to explore new pages, so searching just headers
> by creating
> a list of just the headers is very useful.  The user can then sequentially
> move though just the headers.
>
> The question I have is can this be considered a search or should we have a
> different label like direct navigation?

Received on Wednesday, 11 November 1998 17:33:17 UTC