Re: Navigation Issues joint telecon on May 4

My personal rough estimate of status on the points raised by Jon are marked
by AG:: below.

** Summary:

Generally, I do not believe that there is a lot of change that should come
out of this consultation as regards what goes in the User Agent Guidelines.  

Some possible points of cleanup:

a) Completely hiding MAP elements as a class (as discussed currently in the
UA Techniques) is not the most obvious and desirable technique to cooperate
with the use of MAP in making head navigation bars less of a barrier.
Helping the user read the TITLE of the MAP and then optionally step past
the MAP contents is a more basic technique, higher in priority for the UA
to cover.  The 'hide' technique may also be available, but if only one is
implemented, it would be better it not be that one.

In addition, even 'though the WCAG recommends the MAP element as the
container of choice for head navigation bars, the User Agent should
implement the ability to step past containers in general as a higher
priority feature than any special treatment of MAP per_se.

b) The minimum requirement for the UA as regards HTML H1-H6 is to treat
them as hotspots, whether or not there are assumed to be corresponding
containers or articulable subdivisions of the page content.  These hotspots
provide preferred navigation destinations, and logical places to start
serial reading, with author-supplied orientation information enclosed.
This orientation role should be reflected in UA view construction.  This is
true independent of how much the author has employed them hierarchically or
not, and independent of how much the UA has done to ascertain the level of
hierarchy-thinking on the part of the author.  

c) in HTML TABLEs the discussion in the UA Techniques misses the SCOPE
element.  See notes below and definitions in the HTML Recommendation.

Note (non-cleanup): The most common top level functional subcomponents in a
web page are the head and foot, and then, not quite so universally, the
local-navigation bar commonly found at the left margin in languages written
left to right.  So far as I know there is no reliable markup pattern from
either HTML or the WCAG that will let User Agents recognize even these most
common structural features confidently.


I keep harping on this because PF would like to have a better theory to
advocate to XML dialect creators, but may need help in discerning the
actual structural features that are common in web literature before
selecting a theory or model to be covered by markup capabilities.  This
would appear to involve a triangle of WCA, PF and the HTML WG acting
together.  With help from ER, perhaps.

** Details:

At 09:31 AM 2000-04-20 -0500, Jon Gunderson wrote:

AG:: Note that the User Agent Accessibility Guidelines are in Proposed
Recommendation status at this time.  For the status quo on this topic,
refer to the PR version of the UAAG, especially Checkpoints 8.6 and 7.6
which may be conveniently found at

<http://www.w3.org/TR/UAAG10/uaag10-chklist.html>

>Issue #1: The use of MAP for marking groups of links.
>A. Conventions for accessible usage

This depends on the role of the group of links in the page.  If the page is
a page of search results, then the prime content of the page is a list of
links and there is no reason to encase this list in a MAP element.

The MAP element is recommended practice when a group of off-page links is
incidental to the prime mission of the current page.  And the group of
links is not already collected in some other structure such as a list or
table.  The assumption is that by creating a superelement containing the
group of links, the group can be reviewed by title and optionally skipped
as a group.  This assumes two things from the user agent: 

First:  Elements having a TITLE attribute will be represented in a
navigation-guide view in the User Agent by that TITLE [with possible
exceptions for things like a TABLE which has a CAPTION where the CAPTION
may or perhaps should supercede the TITLE in identifying this page component. 

Second:  That in navigating internal to a navigation-guide view in the User
Agent, it will be possible to skip page components by a stepping to the
next peer in the navigation tree, or next entry in the navigation-guide
view.  What comes next in the current navigation-guide view is subject to
a) ordering in the equivalent-source view, and filter rules b) which
attempt to hit the high spots relative to the current depth in the contents
tree, c) which may contain heuristics that the UA developer has developed
by surveying current web usage and user testing and d) the user may have
some input to per UA checkpoint 7.7.


Third:  A navigation-guide view may be exposed either as a virtual
hypertext or may be implicit in the behavior of the motion commands 'next,'
'enter [also possibly known as 'push' or 'down'],' 'up [also possibly known
as 'pop'],' etc.  In this case the view structure is the graph laid out by
repeated application of these commands.

>B. Labeling the group of links (i.e. use title?, class?, name? or block 
>element labels...)

First priority in display should go to built-in labels such as CAPTION on
TABLE that are exposed in the author's default view and defined in the
document format.

Second priority for display in identifying navigation targets in a
navigation-guide view is the TITLE attribute from the element at the root
of a document component's DOM subtree.

Exposing NAMEs for NAMEd anchor elements is potentially useful but
unproven.  I would view this technique as experimental at this time.

CLASS tokens are to be used in the markup.  They should be mnemonic for the
generic rhetorical role of the document component that they describe.
Their primary use is by the creators of third party stylesheets, but users
should also have access to these properties as discussed previously with
regard to UAAG guideline 2.1.

CLASS values can be used to refine view-filter rules in structural
navigation but this technique is one I would consider experimental at this
time.

The role of the CLASS attribute is to create a subtype of the element type
for the element bearing this attribute designation.  CLASS is to be used
along with the element type name wherever the User Agent addresses the
"What's That" user question.
For reference, this question is intended to be as in the following
four-question orientation agenda:

1. Where am I?

This is a question to which the response is information about the
neighborhood of the current location in the contents hierarchy.  Often
answered with just a location key, i.e. the path between the current
location and a recognizable location reference such as the whole page (c.f.
BASE in HTML and XML).  In tables, location by row and column both is
required.  A tree-descent path is not enough.  More or less contextual
information may be presented.  When at the root of a page decomposition,
the links in the head navigation bar are a high priority to expose in this
"context" sub-view.  External things that one [the current location/scope]
is related to are all part of the context information, although it is
generally useful-to-necessary to have some filtering available in reviewing
this body of information.
2. What's That?

This is a question to which the response is a characterization of the
current location/scope.  [I keep saying location slash scope.  The point is
that a location in the contents decomposition space is a scope in the
document space.]

Top priority: identification of the current location slash scope as
provided by the author or content source.

Additional ad lib and ideally adjustable or probeable:  type information
concerning the current location slash scope.  This includes subtype
information which includes the values of attributes of a container element
specific to this location/scope.  In the case of a constructed view where
the containers in the virtual table of navigation page do not have a unique
ancestor in the base document structure, then the filter and composition
rules for constructions of the virtual entity are part of the type
information that is in this sub-view.


What's There?

This question is answered with a [summary] report on the contents of the
current location/scope.

This report is logically equivalent to the generation of a
table-of-navigation virtual document for the current location/scope.
Filter rules are adjusted to admit more detail as the scope contracts as
the navigation descends through the scope hierarchy.

What Can I Do?

This question is a slanted report on the contents and context which has
filter rules favoring action opportunities.  Immediate action opportunities
may be directly described in this sub-view or they may be represented by
major outcomes reachable by action sequences that start at the local action
opportunities.  For example "win this car" may be the legend for a link
that takes one to a page bearing a form to enter a raffle.

Those four kinds of information are the basic orientation agenda and the
workload is shared between what the user can readily recall and what they
need to be presented with so that they can recognize it.  Naturally, the
presentation emphasizes what is new after a location slash scope change,
but some of the old will be folded into the presentation of content as
well, and it will be discoverable by "where am I" etc.
Orientation must be viewed as defined in terms of what the user
understands.  There is understanding of the current state of navigation,
basically the user's understanding of the answers to "Where am I," and
"What's that?"  In addition there is orientation to "What can I do" in the
way of further motion, or changes to the location slash scope state.  This
is typically answered by the "What is there?" answer which is mostly fresh
after a motion.  "What is there" exposes a structured view of the content,
and structural navigation constitutes moving the current location and scope
among those possible values [or up, etc.].

>C. Can map be used for more than indicating groups of links?

Its primary use is in providing a collection of links which are presented
to the user as active hotspots in an image.

This use is consistent with the use of this element in the recommended
markup for navigation bars that would be implicit unless wrapped in further
markup.

The GL group has not explicitly tried to articulate what MAP should _not_
be used for.  It is considered that use outside of these two uses is highly
unlikely.  However, note that:

The User Agent is not being asked to dedicate any special processing to the
MAP element type per se.  Containers in general, and especially containers
with TITLE set, should be given priority treatment in the structural
navigation functions of the User Agent.  The recommended use of MAP for
header navbars will fall within this class.

>Recent proposal for MAP techniques by Wendy Chisholm :
>http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0016.html
>
>=====================
>Issue #2: Marking up blocks (chunks) of information
>Problem: Many sites have navigation bars, advertising, search forms and 
>then a changing content area(s).  For people using speech when they move 
>between pages in these sites they often think they have not gone anywhere, 
>since the pages all sound the same at the beginning.

>
>My questions are:
>A. What ways (if any) are there to mark up blocks of information for 
>improved navigation

AG::

1) this is a research topic; there is no one answer. 

2) lead them off with an Hx header element

3) reflow the parse tree as indicated in the example at
<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0199.html>.

4) follow the practices in the DAISY/NISO Structure Guidelines, see
references in following mail.


>B. What can be done by authors (using some type of navigation links like
MAP)?

AG::

So far as I can tell, there are two issues combined in the question, that
it would be good to separate.  MAP as a container, and navigation links as
something to be bundled using MAP.

For structural navigation, it is the container role, and a
skip-whole-container action, that are relevant.  It is not the navigation
links inside the MAP which support structural navigation, but the wrapper
outside.

If an author provides intra-page navigation by hyperlinks that have
destinations within the current page, that can be helpful.  It is not
particulary required by the WCAG.  The processing of these hyperlinks is
not viewed as special structural navigation processing but rather as simply
the implementation of hyperlinking as per HTML.

However, the GL group has not consensed on intrapage link usage
recommendations other that as a technique to skip incidental frontmatter to
get more speedily to the main content of the page (see proposal cited above).

It may be beneficial to alert the user that they have moved within the same
page on executing an internal link.  The GL group has not studied this
enought to offer guidance to the UA group on this point.  This is related
to "notify when focus migrates between viewports.  The UA group has a
better handle on the issues here than the GL group, so far as I can tell.

The only safe technique in HTML4.01+WCAG is to cook the parse tree similar
to the example at
<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0199.html> and
use human-understandable TITLE (or other labels, see above) to aid the user
in reading or skipping the substructure one is currently at [the start of].
 At least this is where the PF group has come down in terms of making SVG
drawings comprehensible.  Elements of type svg:g with a svg:title in them
are treated as significant objects and may be considered to be listed out
for explanatory purposes following the nesting (ancestor, not necessarily
parent) relationships these elements have in the parse tree.

The situation in talking books is in flux, with hopes for a convergence
with Open Electronic Book specifications in the future.  So a general sense
of how structural navigation should work for a document that has a
reasonably narrative flow in its core and a reasonable tree structure in
its contents view may be gained from the DAISY/NISO documents.  But the
markup which keys this behavior cannot be regarded as firm at this time
[personal opinion].  The resulting navigation structure, however, is a
workalike for the markup practices discussed above.
>C. What markup will be required to be recognized and processed by user
agents?


AG::

These include, but are not necessarily limited to, headers, subtrees, and
relationships between a table cell and related information.

Headers which are marked by the author with html:h1 .. etc. elements are
very good destinations to include in a navigation-guide view.  This is
independent of the extent to which the author is working from a
hierarchical, linear, or collection (a.k.a. 'bag' in RDF) concept of the
content.  Headers are understood and used often enough by authors as
"orientation for what comes next" so that they should be high-priority
content for inclusion in a navigation-guide view. 

One of the things I have learned from the talking book project is that
while navigating through a hierarchical contents decomposition (as above)
is highly prized by the literate, that many consumers just want you to tell
them the story that is in the book, and play the sound stream of the
talking book much as one would play an audio tape.  The flat, linear
structure of the book is more primitive and more universally usable than
the hierarchical structure.  HTML Headers are like the things that get
listed in the table of contents for a book.  They not only contain titles
for the sub-parts that are organized into a hierarchy in the contents
decomposition view, but they are also better-than-average starting points
in the linear play-the-tape view.  The reader can resume from having
stopped anywhere.  At chapter or section breaks, the reader can stop with
the minimum baggage that they have to carry forward in terms of reading all
they read before, and with the maximum help from the author in getting
started again because there is a heading or section title to orient them to
what is coming.
For any container (i.e. non-empty) element with a good descriptive label:
(where 'good' is recognized as follows...)
For an implicit DIV in ISO HTML, the label is the associated header.
For a TABLE, the label is the CAPTION if present, will fallback to a
SUMMARY if present and CAPTION is absent with fallback to a TITLE on the
TABLE element thereafter.
For navigation bars appearing before the logical start-content point MAP is
suggested as the container of choice.
[etc. other special structures]
For elements in general, the TITLE attribute should generally be used as
label or identification for the substructure contained within that element,
when a TITLE attribute is present.

Subtrees are recognized in the DOM.  Availability of a good text label as
discussed above raises the priority of a subtree for inclusion in the
navigation-guide view.

The WCAG technique of using MAP to collect navbar contents assumes that the
UA will provide the navigation capability to move the current location past
a subtree such as this MAP with one navigation action.

Table cell association with related information.  The discussion of this
topic in the UA Techniques is missing the 'scope' attribute.  There are
three layers of precedence in defining what other information pertains to a
cell in a table.  The highest precedence is an explicit 'headers' attribute
on the cell itself.  The second order of precedence, used only if the first
is not applicable, is if the cell falls within the scope indicated in the
'scope' attribute on the corresponding header cell.  The search for headers
which occur earlier in the row and column respectively is the third order
of precedence.  Headers or effective headers are associated with a cell if
they are found by applying the highest applicable order of precedence
method above.  If a header cell has an 'axis' attribute, this relationship
extends the chain of related information containers for all cells
associated with that header cell.  Regardless of how the cell was
associated with that header.  This is only an heuristic overview.  The
definitive description of this is in the HTML 4.01 recommendation.  The
WCAG has not altered the definition of these relationships.


>================
>The techniques for the following checkpoints in the User Agent Guidelines 
>relate to navigation:
>
>7.3 Allow the user to navigate all active elements. [Priority 1]

These can be detected from the markup as follows:

elements with an action assigned in the markup language, e.g. html:a,
html:button, etc.

elements with an event linked to a script, e.g. html:onHover.

>7.4 Allow the user to choose to navigate only active elements. [Priority 2]
>
>7.6 Allow the user to navigate according to structure. [Priority 2]
>

AG:: One has to consider 7.6 in the context of 8.6 as well; one cannot
define what is required in either by itself.  Structure navigation [outside
tables] is just up down and next in a tree of scopes + hotspots.  The art,
and make-or-break points, are all in the associated orientation features.

>7.7 Allow the user to configure structured navigation. [Priority 3]

User configuration and User-Agent designer selection and heuristics can
both contribute here.  The better one is, the less you need of the other.
But the best design still probably combines element of both.

AG:: 

>8.4 To help the user decide whether to follow a link, make available link 
>information supplied by the author and computed by the user agent.
[Priority 3]

AG:: Yes, there should be computed information when the User Agent creates
a virtual hyperlink as part of a navigation-guide view.  If the destination
is a header, the header content is the appropriate virtual-link
information.  If the destination is some other container, the link
information is [if a FORM or TABLE, the type and] the good label as
discussed above.

>
>IMPACT: The results of this discussion could affect the minimum 
>requirements for satisfying one or more these checkpoints.

AG:: Minimum implementation in a UA is ultimately a UA question.

Al

>
>Jon
>
>
>
>
>
>Jon Gunderson, Ph.D., ATP
>Coordinator of Assistive Communication and Information Technology
>Chair, W3C WAI User Agent Working Group
>Division of Rehabilitation - Education Services
>College of Applied Life Studies
>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
>WWW: http://www.w3.org/wai/ua
>

Received on Wednesday, 3 May 2000 15:47:35 UTC