Re: proposal for wording re: grouping links (WCAG techniques document)

Let me try again:

I think that there are several related things here:

* Validation of QuickStart performance in low-vision and no-vision usage
scenarios.

* Structural navigation within a page.

* Navbars as functional groups.

* The skip-navigation link.

The QuickStart performance factor belongs in a role similar to a guideline
in the Validation Techniques discussion.  

n. Performance Factor
n.m Validation technique 

etc.

The evaluation question for QuickStart capability is "can users with no
visual display or viewing only a small fraction of the normal scope
displayed surely and rapidly move to the meat of the page, where the
information is conveyed that one only learns by visiting this particular page.

This factor is a big problem in practice and deserves priority in planning
and budgeting for user testing.  In other words, until your site is under
the control of a design practices guide which has been proven through user
testing to support this QuickStart capability, get the site and prototypes
for new site designs evaluated by qualifying end-users for this question.

Recommended action: develop this topic in the Validation Techniques section
of the WCA Techniques.

Structural Navigation

I do believe this is the way we want to head for XML.  In HTML we are
starting at a disadvantage; it is not even clear what one will get for a
parse tree from many pages.

This is also an area which is not as clear in the WCAG as one might wish.
We have a variety of guidlines that dance around this issue but never
really address it squarely.

    + 3. Use markup and style sheets and do so properly.
    + 12. Provide context and orientation information.

    + 13. Provide clear navigation mechanisms.
    + 14. Ensure that documents are clear and simple.

One of the key points is that to maintain a clear and consistent page
organization across the site, two simple techniques that really help are
the following.  

  (1) Write it out:  Write down a site structural plan and style guide.
Follow it.

  (2) Write it in:  Use markup, especially TITLE attributes, to say how the
parts of the pages follow the plan.  Add DIV if you need a collector to
show the block structure.  TIP: if you use separate database queries to
populate successive portions of the HTML, make each portion a separate DIV
and relate the TITLE of each to its query.

This is the point where I believe that the cognitive and blind interests
line up in agreement.

Recommended action: strengthen section 3.5 of the WCA Techniques to talk
about making the block structure visible in the parse tree with the aid of
DIV if needed, and the roles of the blocks clear in the TITLEs of the
elements which root the principal parts of the page and their respective
principal sub-parts.  There is a document structure problem that this
combines a variety of checkpoints.  It would be better for this topic if
the techniques were not farmed out under single checkpoints.

In the user agent, some combination of markup and heuristics will make
structural navigation useful, but we have not really found out what
combinations work and which don't.  Either it's all going to be heuristics,
or the authors are going to need some automated feedback from the author
tools to make this work.  

It seems to me we need at least one reference method for automatic List of
Contents extraction for a page if we are going to get very far with this.
This reference method needs to be the same in UA and AU documents, or
presented in one place and cited in the other.


Recommended action: ask ER-IG to consider, test, and recommend methods for
extracting an effective document structure for existing pages.  Capture the
result in to the UA and AU documents.

** Navbars as structural groups.

Because of the time it takes tabbing through links in audio mode, these
should be explicitly grouped in a container both for ease of skipping when
they appear before the meat of the page and in order to make it easy to
navigate to them through structural navigation.  MAP is arguably
specifically for this purpose, although this is probably not a widely held
idea among authors, yet.  For the purposes of user agent structural
navigation, it is not clear that a MAP should be treated much different
from any other collector but one could announce it as a navbar if it is
marked MAP.  For orientation to the parts of a page TITLE should take
precedence over element types for presentation to the user when present.

Recommended action:  Use MAP in the specific technique and examples for
"grouping related links."  Do not suggest that TITLE be given a fixed,
conventional value.  Title for navbars should be selected to reflect the
specific structural plan of this site.  Examples of titles for the first
navbar at the top of the page might be "Credits," "QuickLinks around
BozoVille," etc. 

** Skip-navigation link.

This is needed at the present time.  The "until user agents" clause could
be something like "until user agents support structural navigation which
will guarantee a quick path to the meat of your pages."  Those who find a
visible link esthetically undesirable may hide this link using a one-pixel
image with an ALT explaining the skip-navigation function.  If there are
more than, say, five links before the meat of the page, there should be one
of these links as the first or near the first link on the page.  Link
counting is done without regard for TABINDEX in this case (until user
agents...).

Recommended action:  State this technique somewhere in the WCA Techniques.
It is actually better to do it in the new 3.5 under general navigation than
under "groups of links" because the specific group of links one would wrap
in a MAP is often less than the frontmatter one would skip with this link.
A typical setup includes multiple bars within the frontmatter.  Use it in
the example of MAP for navbars, but don't define it there for the first time.

Summary:

Using MAP for navbars is fine, but it does not solve the QuickStart
performance problem until user agents implement corresponing structural
navigation, and it does not fully answer the User Agent question "How
should we interpret markup in order to deliver structural navigation."  In
addition, the Validation Techniques section should address the QuickStart
performance issue as a topic, because it is a major quantitative problem in
the field today and understanding the issue will help web content authors
respond with effective relief.

Al

Received on Saturday, 28 August 1999 18:40:19 UTC