W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1998

RE: navigating Vs searching

From: Jon Gunderson <jongund@staff.uiuc.edu>
Date: Fri, 13 Nov 1998 10:05:03 -0600
Message-Id: <199811131607.KAA10796@staff2.cso.uiuc.edu>
To: "Markku T. Hakkinen" <hakkinen@dev.prodworks.com>, "Al Gilman" <asgilman@access.digex.net>
Cc: <w3c-wai-ua@w3.org>
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?

At 05:32 PM 11/11/98 -0500, Markku T. Hakkinen wrote:
>Navigation Styles: Does Separating Content from Presentation include
>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:
>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"
>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.
>> 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
Received on Friday, 13 November 1998 11:08:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:21 UTC