[g-a-devel]Re: Auto-completion popup?

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-05-28 at 06:54, Bill Haneman wrote:
> Hi:
> 
> > > OK, well I am not very comfortable with this proposal.  It is definitely
> > > an accessibility problem to have popups appearing without a more
> > > explicit user action.  I think on-demand completion is that way to go;
> > > however you are correct in saying that it should not be "TAB".
> > I think this is misguided. You are suggesting effectively removing an
> > extremely useful and important feature, basically, for lack of a way to
> > communicate to the AT what is going on.
> 
> I think that's an overstatement - the same argument could be made that
> any new keycombination is "esoteric".  Users find new keycombinations
> through reading manuals, "hints" dialogs, asking people, Release Notes,
> etc.  The alternative of just popping the feature up in the users' faces
> has its own disadvantages, and accessibility is just one of the cases
> where it's not clearly the best way to expose a feature.

There are very few, if any, "hidden" features of GTK+ that you need to
know a key shortcut for. The F8 GtkPaned keynav, and Control-F1 
tooltips browse mode are all I can think of, and they are simply
alternative methods for something you can also do with the mouse.

> > (I say removing, because most users won't find completion if they
> > need to use an esoteric key combination to get to it.)
> > 
> > > However word completion can't be something that's accessibility
> > > unfriendly, under the assumption that it's a "convenience" - since it's
> > > a useful feature, a desktop that doesn't provide an
> > > accessibility-friendly way of using it is by definition not fully
> > > accessible.  So turning this off is not, IMO, a good option for us.
> > 
> > If the AT simply knew enough to know that the completion popup 
> > was extra "auxiliary" information to the main work flow, then
> > it could avoid telling the user about it until they hit down arrow to
> > select the first completion.
> 
> This is possible - we would need new ATK_ROLE types for this, and ATs
> would need the appropriate logic for dealing with the result.  I presume
> that the keyboard focus would remain on the text entry field
> until/unless the user pressed the arrow keys?

Yes.

> Note that there's another awkward bit of "modality"/statefulness here -
> if the (blind) user isn't told that the popup is there as soon as it
> appears, then the affect of the arrow keys will have changed (from
> navigation through the focus-chain for the dialog, to navigation within
> the popup) without any notice.  That's bad, but perhaps the interruption
> of having "Popup: word completion!" being spoken all the time, or placed
> on a braille display, would be worse.

The natural thing here is to simply never allow down to focus out of
an entry ... entries already trap left/right, combos and spinbuttons
currently trap up/down; the fact that entries allow down to focus
out is more surprising than anything else.

Regards,
                                      Owen