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

Guideline 7 - 7.1, 7.2, 7.4, 7.5

From: Kitch Barnicle <barnicle@trace.wisc.edu>
Date: Wed, 24 Nov 1999 10:32:16 -0600
Message-Id: <Version.32.19991123103337.00f0d3c0@trace.wisc.edu>
Message-Id: <Version.32.19991123103337.00f0d3c0@trace.wisc.edu>
To: w3c-wai-ua@w3.org
Hi,

I'm sorry for the delay in addressing this action item. As it is, I had to
break it up into pieces and finish what I could now and skip some sections.
I'll keep working on the other check points but I hope others feel free to
comment on Techniques for guideline 7.

Happy Thanksgiving,

Kitch


Guideline 7. Provide navigation mechanisms

7.1 Allow the user to navigate viewports (including frames). [Priority1] 

Note. For example, when all frames of a frameset are displayed side-by-side,
allow the user to navigate among them with the keyboard. Or, when frames are
displayed individually (e.g., by a text browser or speech synthesizer),
provide
a list of links to individual frames. Navigating into a viewport makes it the
current viewport. 

Comment: I would change the wording of the Note for this checkpoint. In some
cases, frames are not displayed individually but rather accessed individually
or one at a time. 

Suggested Rewording:
Note. For example, when all frames of a frameset are displayed side-by-side,
allow the user to navigate among them in a device independent manner,
including
with the keyboard. Or, when frames are accessed or viewed one at a time (e.g.,
by a text browser or speech synthesizer), provide a list of links to
individual
frames. Navigating into a viewport makes it the current viewport. 

Techniques 1:

Current Version: 
* Some operating systems provide a means to navigate among all windows, not
just
those created by the user agent. This suffices for viewports that are windows.
However user agents may also allow the user to shift the focus from window to
window independent of the standard operating system mechanism. 

Comment: This technique sounds a bit confusing since I think it is meant to
refer to the ability to switch between windows with the keyboard. Should we
add
"in an input device independent manner"?

Suggested Revision:
* Some operating systems provide a means to navigate among all open windows
using multiple input devices (e.g. keyboard and mouse). This technique would
suffice for switching among user agent viewports that are separate windows.
However, user agents may also provide a mechanism to shift the focus among
user
agent windows, independent of the standard operating system mechanism. 

Technique 2: Consult the section on frame techniques. 

7.2 For user agents that offer a browsing history mechanism, when the user
returns to a previous view, restore the point of regard in the viewport.
[Priority 1] 

For example, when users navigate "back" and "forth" among views, for each view
they should find the viewport position where they left it. 

Current Techniques: None

Comment: I think we need to make a distinction between the situation when a
user hits the "back" and "forward" buttons versus the situation where the user
choose a page from the list of pages in a history view. When a user hits the
back button, I believe that not only should the view return to its previous
position but the focus should return to the "last item" that had focus.
This is
especially important for users who are using sequential navigation (e.g.
tabbing).  However, when the user chooses a page from a history list I don't
think the view or focus needs to be restored to where it was the last time the
user was on that page. Does that make sense? I don't want developers to be
confused because the checkpoint mentions "history mechanism."  Is this issue
covered some place else?

Suggested Technique: When a user returns to a previous view using a user
agents
"back" and "forward" function, restore the point of regard in that view and
return the focus to the item that last held focus in that view.  


7.3 - Table cells navigation - I skipped this checkpoint for now it is
going to
take me some time to go over it. I hope others feel free to comment on this
section in the mean time.


7.4 Allow the user to navigate all active elements. [Priority 1] 
Navigation mechanisms may range from sequential (e.g., serial navigation by
tabbing) to direct (e.g., by entering link text) to searching on active
elements only (e.g., based on form control text, associated labels, or form
control names). 

7.5 Allow the user to navigate just among all active elements. [Priority 2]
Refer also to checkpoint 7.4. 

Techniques:

Current Technique 1: *Sequential navigation includes all active elements. User
agents might provide other navigation mechanisms limited to a particular type
of element. For example "Find the next table" or "Find the previous form". The
following techniques suggest some types of navigation.

Suggested Revision: Allow the user to sequential navigate through all active
elements using a single keystroke (e.g. tab key, key of user's choice). User
agents might provide other sequential navigation mechanisms limited to a
particular type of element. For example "Find the next table" or "Find the
previous form". The following techniques suggest some types of navigation.

Comment: Is serial navigation different from sequential navigation? They mean
the same thing to me.

Current Technique: *Serial navigation. It is important that application
developers maintain a logical keyboard navigation order. The navigation order
is defined as the order of navigation among components and component elements
via the keyboard. Generally users navigate by tabbing between components or
groups and using the arrow keys within a component group or component's
elements. The ability to tab between software components is a key feature in
the implementation of keyboard accessibility. (Cross-reference to keyboard
access.) Buttons of common functionality, such as a set of radio buttons used
to set the location of a panel (top left, bottom left, and so on.), should be
grouped together so the first element of the visible group can be tabbed to.
Allow the user to use the arrow keys to navigate to each end of the group. 

Comment: I am confused about the distinction among "active elements,"
"components" and "component elements" and just plain "elements."  Is a single
radio button of a form control a component element while the set of radio
buttons is a component? If yes, then what is the active element the group of
radio buttons? Also, I'm not sure what is meant by the example, "set of radio
buttons used to set the location of a panel..." 

 How to indicate that something is in tabbing order in Java: A component is
inclusive in the tabbing order when added to a panel and its
isFocusTraversable() method returns true. A component can be removed from the
tabbing order by simply extending the component, overloading this method, and
returning false. 

Comment: I'll need someone else to comment on this technique.

 For active elements, navigation to the previous or next active element.  
Comment: I'm not sure what is meant by this technique. Is this where we
want to
suggest allowing the user to sequential move through a particular kind of 
active element.  For example, allow the user to sequential jump among types of
elements in a document  - a) links, b) forms , c) tables. 

 In a table, up/down and left/right.  - skipped for now


Current Technique: Direct navigation: Excessive use of serial navigation can
reduce the usability of software for both disabled and non-disabled users.
As a
developer, you need to determine the point at which tabbing gets in the way
and
provide a keyboard alternative. This is done through the use of keyboard
shortcuts. Note that user agents must provide information about available
shortcuts (the current keyboard configuration) to users.

Comment: I think we should add a heading like "direct navigation techniques"
and label the technique above keyboard shortcuts or keyboard alternatives or
something similar.

 Need for element identification.  

Suggested Technique: 
Assign each active element a unique identifier. For example number each active
element in a document. 

 Access by position in document. 

Suggested Technique: 
Include a  "go to" feature that would allow users to move directly to an
active
element based on some identifier. For example, allow users to go directly to
the 16th active element in a document. 

 Next/Previous occurrence of text in an element's content (e.g., first
letter)
in the current document. 
Suggested Technique:
Allow the user to jump to the next and previous active element based on
text in
the element's content, (e.g. first letter.) 

 In a table, access to cell based on coordinates.  - skipped for now

Checkpoints 7.6-7.8  - skipped for now
Received on Wednesday, 24 November 1999 11:32:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:34 GMT