RE: navigating Vs searching

This is a interesting concept of user/author navigation sheets.  My main
question is where the burden of the "ACCESSKEY style sheets" would be
placed and how general would the styles sheets be across pages?
Jon


At 05:32 PM 11/11/98 -0500, Markku T. Hakkinen wrote:
>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?
> 
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 Friday, 13 November 1998 11:08:19 UTC