Re: lynx-dev patch that allows text inputs to be non-sticky

[asgilman]

What follows is educated hunches.

I have some idea that people using screen readers would find it confusing to 
drop into an edit field and the keystroke vocabulary suddenly change under them.

In other words, the pre-2.3 behavior where one had to manually open an entry
field to enter stuff in it is IMHO more friendly to [a least the novice] 
eyes-free user.  There are more keystrokes but the state changes are obvious.

I have also spoken up on the WAI User Agent list complaining about 
automatically submitting on ENTER for forms that lack a SUBMIT element.
This is a trap for folks who are used to closing a text entry with ENTER.
Generally speaking, forms without explicit SUBMIT are treacherous in 
eyes-free mode where it is harder to know the full extent of the form and
what is being submitted.  Better to be pedantic, so far as I can tell.

These are my rough ideas; I haven't studied the matter systematically.

Al

For what it's worth, here are my nominees for a more explanatory flag
name in lynx.cfg:

One setting is OPEN_ENTRY_FIELDS:AUTO

Its opposite is OPEN_ENTRY_FIELDS:MANUAL

Don't create the hybrid.  If MANUAL, keep it that way for all fields.
It's hard enough to follow the modal changes as it is.

The flag for the other one could be

                FORMS_WITHOUT_SUBMIT_ELEMENT:SUBMIT_ON_ENTER

                FORMS_WITHOUT_SUBMIT_ELEMENT:INSERT_ELEMENT

>     * Subject: Re: lynx-dev patch that allows text inputs to be
>       non-sticky
>     * From: "Lloyd G. Rasmussen" <address@hidden>
>     * Date: Wed, 28 Jul 1999 15:31:35 -0400
>   
>I have no idea.  I run Lynx with show_cursor on.  The cursor is either on a
>field or on the status line.  That's all I know.  Status line messages need
>to be informative, as they usually have been in Lynx.
>
>
>At 11:18 AM 7/28/99 -0600, you wrote:
>>In a recent note, Vlad Harchev said:
>>
>>> Date: Tue, 27 Jul 1999 09:10:14 +0500 (SAMST)
>>>
>>>  As I described in my previous message, the cursor is blinking in 'entered'
>>> textinput, and not blinking in 'not yet entered'.
>>
>>How does this work in audio and Braille?
>>
>
>Lloyd Rasmussen, Senior Staff Engineer
>National Library Service f/t Blind and Physically Handicapped
>Library of Congress    (202) 707-0535  <address@hidden>
><[13]http://www.loc.gov/nls/>
>HOME:  <address@hidden>   <[14]http://lras.home.sprynet.com
>     _________________________________________________________________
>   
>     * References:
>          + [15]Re: lynx-dev patch that allows text inputs to be
>            non-sticky
>               o From: Vlad Harchev <address@hidden>
>          + [16]Re: lynx-dev patch that allows text inputs to be
>            non-sticky
>               o From: address@hidden
>       
>     * Prev by Date: [17]Re: lynx-dev non-sticky text inputs
>     * Next by Date: [18]Re: lynx-dev non-sticky text inputs
>     * Prev by thread: [19]Re: lynx-dev patch that allows text inputs to
>       be non-sticky
>     * Next by thread: [20]Re: lynx-dev patch that allows text inputs to
>       be non-sticky
>     * Index(es):
>          + [21]Date
>          + [22]Thread
>     _________________________________________________________________
>   
>   [23]Lynx mailing list archives
>   
>   [24][FLORA HOME] [25][LYNX Home]