Re: Auto-completion popup?
- From: Owen Taylor <otaylor redhat com>
- To: Bill Haneman <bill haneman sun com>
- Cc: Kristian Rietveld <kris gtk org>, GTK Development list <gtk-devel-list gnome org>, gnome-accessibility-devel gnome org
- Subject: Re: Auto-completion popup?
- Date: 28 May 2003 12:49:01 -0400
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]