keyboard navigation.doc

Keyboard Access to Web Documents


Point of Regard


Providing keyboard access to web documents requires the addition of a
viewing concept.  The User Agent Guidelines already discuss the concepts of
"selection" and "focus."  Selection is the unit or set of units of content
that would be copied, cut, or pasted by an operation. Focus is the element
that would react to a user action.  This includes activation of links and
controls.  The additional concept is "point of regard," which is the portion
of a document that is currently under consideration.  Both selection and
focus generally would lie within the point of regard, but would not
necessarily encompass the same number of document elements.


Hunting vs. Browsing


In considering access to web documents, we should provide for two types of
access intent, which might be considered hunting versus browsing.  The
current guidelines focus on the concept of hunting on the web.  For example,
if I am searching for a specific word or set of words, the current document
supports searching the current page via keyboard commands.  Moving from link
to link via keyboard commands also supports the concept of hunting.  The
underlying concept of "hunting" is that the user already knows at least part
of the information that is being sought, and uses that knowledge to guide
the search for more information.

In contrast, when browsing, an individual might be seeking information to
simulate a line of thought.  This is similar to browsing in a library, where
a reader might move along a shelf, looking at titles.  When a title looks
"interesting," the reader might remove the book and examine it more
closely.  In like manner, a "browser" on the web might enter a page looking
for a topic that stimulates interest, without any preconceived idea of what
that information might be.

Keyboard navigation of the web should support both hunting and browsing. 
The techniques used in the two types of search might be very different.

 


Hierarchical navigation of web documents via keyboard commands


Allow the user to move through the document in chunks.


In browsing a web document an individual may wish to move through the text
in chunks.  At the lowest level, these chunks might be paragraphs or list
items.  A logical model might be to define a document chunk as the text
lying between two block level HTML tags of the same level or type.  Using
intuitive keyboard commands, the user should be able to move the point of
regard to the beginning of the next or previous chunk of text. Note that it
is not adequate to move through the document using "Page up" and "Page down"
commands to move to the next screen, as this will generally begin in the
middle of a block of text, and is disorienting to a screen reader.

When the user moves through a document through keyboard commands, the focus
should move with the point of regard.  If the current chunk has no object
that can accept the focus, the focus should remain on the last
focus-accepting object.  When the current point of regard contains a
focus-accepting object, the focus should move to the first object within the
chunk that can accept it.


Allow the user to change the chunk size.


A user should be able, via keyboard control, to change the chunk size.  The
most logical method of doing this might be to establish a logical hierarchy
of block level tags.  For example, list times are lower in the hierarchy
than list starts.  H3 tags are lower than H1 tags.  Via keyboard control,
the user should be able to expand or shrink the chunk, thus changing the
distance a "move down" or "move up" command would shift the point of regard.


Provide a cue to the user to indicate the current chunk size


The user agent should provide some indication to the user of the scale of
the current chunk size.  This should not be the same indicator as is used
for indicating selection, as it may be desirable to select either a portion
of the current chunk, or several document chunks at a time.  The methods
used to indicate selection and point of regard should be compatible, but not
identical.


Provide alternate controls for making selections and for activating
contextual menus


An able bodied user may use the mouse to select a block of text, then use
the same mouse controls, often by holding down a mouse button, to activate
contextual menus for saving, cutting, or copying the selected text.  This
presents a problem for the individual with a disability who may not be able
to move the mouse quickly within a document.

To provide equivalent access, a user agent should provide alternative
controls for making selections and for activating contextual menus that are
not temporally discriminated.


Below are some areas of the current guidelines that I think might be
modified to provide increased access or at least increased awareness of
access issues.


4.3 Access to descriptive text


Users should be able to activate, via keyboard control, the Title text of an
image, applet, or other object.


This action may be a result of making the object the current point of
regard, which is different from selection or focus.


4.3.2 The longdesc link, when rendered as a link with a "D" caption, should
act as a standard link, including being accessible by keyboard navigation.


4.5 Alternative Representation of Embedded Applications


In cases where an objects descriptive text is of significant size, the user
agent should provide keyboard navigation of the descriptive text that is
equivalent to  that of the document as a whole.


Access to Tables


4.6 Serialization - It looks like the column serialized tables are displayed
incorrectly in the working document.  The content of the "B" cell and the
"E" cell are reversed.


Would it be a good idea to allow the user to dynamically change the display
of tables from row order to column order?  (This would involve a keyboard
control, I'm sure.)  Thus, when the point of regard was on a specific cell,
the user might be able to see what was above and below in one view. By
activating a keyboard command, the user could re-render the table to show
the cells to the right and left, without changing the point of regard.


Orientation Guidelines


5.3.3 - Provide a means to indicate the presence of an Accesskey when
defined in a link or form control.  When done visually, the preferred way is
to decorate a letter of the text label or the anchor text that corresponds
to the access key.  When a page is rendered auditorially, this may be done
via tone changes or other auditory cues.