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

[Bill Haneman <bill haneman sun com>]

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.
 
> (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?

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.

My concerns are around the use case here - I am CC'ing
gnome-accessibility-devel because I'd like to hear from BAUM/gnopernicus
engineers on how they'd like this to appear to the end user, since in
particular, deaf-blind users have only a single serial channel for
interacting with the desktop, and popups tend to be difficult to
efficiently express in that situation.
 
> Of course, you really want to *expose* the completion set 
> to the AT so that you can do more interesting things, like
> list the completion choices in an onscreen keyboard.

Of course - we would like to have API for either feeding the completion
dialog from an outside source like the onscreen keyboard, or getting the
completion list and feeding it into the onscreen keyboard.  This would
be a major help.

- Bill
 
> Regards,
>                                         Owen
> 
> 
>