hello,
thanks for your responce. yes i do know about lynx options for viewing
picklists, do you agree that the choice should be mine and the web
designer should not assume or require one choice over another or that one
should be driven to choose to redo the option choice routine only for
using the nls page? i too regret the design choices made, as you say you
share apparently, and request some reconsideration of some of them.
first, the default choices have been made for the user and i find that i
choose to make a different choice for almost every category, this requires
one visiting and going through the lists anyway each time used, despite
which viewing option is chosen.
second, all the text entry lines are in a row requiring one to navigate
through all to get to one of the last and/or then move to the send link to
continue the search. each entry line could be followed by a send link.
third, i know about the other search pages and have been using them from
almost as soon as they appeared. it would be a simple task to hook that
style to the new search engine. the format of having the single text
entry field togather with the few options one can make, is much simpler
and direct then the new form. give the user the choice with equal access
to the new faster search engine.
forth, as you may have read in another subsequent post, i solved these
problems for myself by editing the new form to serve my search needs,
which generally reflect the changes suggested above.
thanks,
dan
On Thu, 30 Sep 1999, Gregory J. Rosmaita wrote:
> dan dunfee recently cross-posted the following comment to a number of lists:
>
> quote
> i just tried the new nls online interface to do a book search, not a pretty
> sight. there are literaly 13 pages of radio button pick items when using
> lynx. it is much faster in getting results, but that interface is a
> travesty. there need to be toggles which present a much simplified interface
> for those who want one. did anyone at the nls consult with blinks, especially
> lynx users, before putting this up? look at:
> http://www.loc.gov/nls/web-blnd/bph.html
> unquote
>
> to which i reply:
>
> aloha, dan!
>
> i don't think that the problem is so much with the interface (although i
> personally might have designed it differently) but with your browsers'
> settings... what version of lynx are you using? if you're note sure, type an
> equals sign while Lynx is running, and the version number should be displayed
> on the third line from the top of the screen -- or, if you prefer, line 3 of
> the 25 lines of the Lynx display area...
>
> it sounds to me as if you have Lynx set to convert list-boxes into radio
> buttons, and that you need to go into the Options menu (which you reach by
> typing an O while lynx is running)
>
> once you get to the Options menu, use lynx's search feature (invoked by typing
> a forward slash) to search for the word
> popups
> (that's p o p u p s)
> and lynx should place you on a line that reads:
> Popups for select fields
>
> check the value that is currently set for this option and if it is set to OFF,
> then use the arrow keys to set it to ON
>
> the reason i asked you what version of Lynx you are running is to determine if
> you are using a version of Lynx that allows you to convert popup boxes -- what
> GUI screen readers call "list boxes" or "drop-down menus" -- into radio
> buttons... if you are using Lynx32, chances are that you _are_ using a version
> of Lynx that is capable of converting popup menus to radio buttons, and that
> you have it set to do so...
>
> you might be curious as to why this option exists, so here is a (hopefully)
> brief historical aside to explain the problems that popup menu support, as
> originally implemented in Lynx, caused:
>
> when running Lynx with the SHOW_CURSOR setting active, Lynx placed the cursor
> at the extreme right of the popup menu it generated when the user navigated to
> a SELECT OPTION form control... thus, the use of popup menus in conjunction
> with a screen-reader often made listening to the form extremely difficult --
> not to mention downright annoying -- for, with the cursor placed at the end of
> the select option text, the only way to expose the content of the option was
> to use your screen-reader's "say-line" command, which, of course, led to
> bleed-through of text from the underlying page content... as a compensatory
> measure, the Lynx Developmental Consortium built the toggle mechanism into
> Lynx, so that the user could decide whether to have Lynx render the options
> contained in the select menu either as a popup box or to render each option as
> a radio button... and for (what was then state-of-the-art) accessibility's
> sake, each radio button was placed on a separate line... so, why precisely was
> the ability to convert select option menus into a series of radio buttons added
> to Lynx? mainly because those actually doing the programming argued that it
> would take considerably more programming time and effort to move the cursor
> from the extreme right of the popup menu box (i.e. after the last character in
> the option), to the extreme left of the popup menu box (which is to say, on the
> first character of the first option in the select option menu -- a placement
> which would allow screen readers to speak the selected option ONLY when the
> user navigated the option list with the arrow keys)
>
> anyway, to make a long story longer, thankfully, wayne buttles -- the man
> behind bobcat and lynx32 -- was willing to take the time to effect the change
> in bobcat and lynx32, which eventually led the Lynx-Developmental consortium to
> do the same...
>
> oh, and one last thing -- if you don't like searching the NLS catalog using the
> form located at:
> http://www.loc.gov/nls/web-blnd/bph.html
> you can always use the older, shorter forms, such as the
>
> 1. Author or Narrator Search Form
> <http://lcweb.loc.gov/nls/web-blnd/bphpauth.html>
> 2. Subject Search Form
> <http://lcweb.loc.gov/nls/web-blnd/bphpsubj.html>
> 3. Title Search Form
> <http://lcweb.loc.gov/nls/web-blnd/bphptitl.html>
> 4. Series Search Form
> <http://lcweb.loc.gov/nls/web-blnd/bphpseri.html>
> 5. the "Number Search" page, located at
> <http://lcweb.loc.gov/nls/web-blnd/bphpnums.html>
> links to 3 separate forms:
> 5.1 Dewey catalog number searches:
> <http://lcweb.loc.gov/nls/web-blnd/bphpdewy.html>
> 5.2 Book Number Search Form
> <http://lcweb.loc.gov/nls/web-blnd/bphpbook.html>
> 5.3 Holding Code Search Form
> <http://lcweb.loc.gov/nls/web-blnd/bphphold.html>
> 6. Keyword Search Form
> <http://lcweb.loc.gov/nls/web-blnd/bphpretr.html>
>
> and if you don't want to cut-and-paste or have your synth read all of those
> URLs into a tape recorder, you can find links to the catalog search interfaces
> by using the following URL:
> http://www.hicom.net/~oedipus/books/libraries.html#nls
>
> gregory
> --------------------------------------------------------
> He that lives on Hope, dies farting
> -- Benjamin Franklin, Poor Richard's Almanack, 1763
> --------------------------------------------------------
> Gregory J. Rosmaita <[log in to unmask]>
> WebMaster and Minister of Propaganda, VICUG NYC
> <http://www.hicom.net/~oedipus/vicug/index.html>
> --------------------------------------------------------
>
VICUG-L is the Visually Impaired Computer User Group List.
To join or leave the list, send a message to
[log in to unmask] In the body of the message, simply type
"subscribe vicug-l" or "unsubscribe vicug-l" without the quotations.
VICUG-L is archived on the World Wide Web at
http://maelstrom.stjohns.edu/archives/vicug-l.html
|
