direct navigation

I have sent some editorial comments directly to Jon but I would like some
input on the following issue.

The current version of the guidelines include the following:

5.3 Direct Navigation

1.[PRIORITY 1]
Allow the user to use the keyboard to move the focus directly to links and
controls on a page. Users should be able to search for (and shift the focus
to) a link or control by its position or by its name


Kitch: I am not sure what you mean by "should be able to search for a link
or control by its position?"  Does this mean position in a list of elements?

Also, while the ability to search for and move the focus to an element or
control is important and should be included, I don't know if it is the
best, or only, way to provide direct access to elements. This issue may not
be as critical if manufacturers provide "alternative views" of pages. 

Please correct me if I am wrong but, could this be one possible scenario of
how someone who uses a screen reader would use the search feature -

He or she might -
1) listen to a web page 
2) may or may not be able easily identify the text in a link, depending
upon how the link is rendered and how the screen reader is configured 
3) issue a "find" command for a word in the desired link 
4) repeat the "find" command since the chosen word may or may not be unique
to that link. this may mean that the user also has to issue "read line"
commands to identify all of the text in a link prior to making his or her
selection
5) and finally, activate the desired link.

If each link and control could be uniquely identified, on user command, by
a number or some other means, it seems that this process of directly
accessing a link would be easier.  In other words, can some of the features
of lynx be built into other browsers?


Kitch

Received on Monday, 1 June 1998 15:21:54 UTC