Probably a dup of bug 348464.

I typed in "t" into the text entry area. This bought up a "list"
with two items in it ("total" and "totally").

With the focus in the Gtk Entry completition area, I typed Insert-F7
to get the current accessible component hierarchy:

+-name='gtk-demo' role='application' state=''
  +-name='GtkEntryCompletion' role='dialog' state='ACTIVE ENABLED SENSITIVE SHOWING VISIBLE'
    +-name=None role='filler' state='ENABLED SENSITIVE SHOWING VERTICAL VISIBLE'      +-name=None role='filler' state='ENABLED SENSITIVE SHOWING VERTICAL VISIBLE'
        +-name=None role='text' state='EDITABLE ENABLED FOCUSABLE FOCUSED SENSITIVE SHOWING SINGLE_LINE VISIBLE'

I arrowed down to the second item in the list of possible
items. This is selected. This generated the following object events:

OBJECT EVENT: object:state-changed:selected            detail=(1,0)
---------> QUEUEING EVENT object:selection-changed
    app.name='gtk-demo'           name='total' role='table cell' state='ENABLED
FOCUSABLE FOCUSED SELECTABLE SELECTED SENSITIVE SHOWING SINGLE_LINE TRANSIENT VISIBLE'

OBJECT EVENT: object:selection-changed                 detail=(0,0)
    app.name='gtk-demo'           name=None role='table' state='ENABLED FOCUSABLE SENSITIVE SHOWING VISIBLE MANAGES_DESCENDANTS'

OBJECT EVENT: object:state-changed:selected            detail=(0,0)
    app.name='gtk-demo'           name='total' role='table cell' state='ENABLED
FOCUSABLE FOCUSED SELECTABLE SENSITIVE SHOWING SINGLE_LINE TRANSIENT VISIBLE'

OBJECT EVENT: object:state-changed:selected            detail=(1,0)
---------> QUEUEING EVENT object:selection-changed
    app.name='gtk-demo'           name='totally' role='table cell' state='ENABLED FOCUSABLE SELECTABLE SELECTED SENSITIVE SHOWING SINGLE_LINE TRANSIENT VISIBLE'

OBJECT EVENT: object:selection-changed                 detail=(0,0)
    app.name='gtk-demo'           name=None role='table' state='ENABLED FOCUSABLE SENSITIVE SHOWING VISIBLE MANAGES_DESCENDANTS'

OBJECT EVENT: object:active-descendant-changed         detail=(2,0)
    app.name='gtk-demo'           name=None role='table' state='ENABLED FOCUSABLE SENSITIVE SHOWING VISIBLE MANAGES_DESCENDANTS'


At this point I typed Insert-F7 again. This gives a component hierarchy of:

+-name='gtk-demo' role='application' state=''
  +-name='GtkEntryCompletion' role='dialog' state='ACTIVE ENABLED SENSITIVE SHOWING VISIBLE'
    +-name=None role='filler' state='ENABLED SENSITIVE SHOWING VERTICAL VISIBLE'      +-name=None role='filler' state='ENABLED SENSITIVE SHOWING VERTICAL VISIBLE'
        +-name=None role='text' state='EDITABLE ENABLED FOCUSABLE FOCUSED SENSITIVE SHOWING SINGLE_LINE VISIBLE'

In other words, it's identical to the first one.

We will need to work out how to determine that we have a table of
possible completion entries for the text entry field and what should
be spoken/brailled when that occurs.

*** Bug 348464 has been marked as a duplicate of this bug. ***

Mike, how would you like the GtkEntry list of possible completions
spoken?

Using a simple cut-down version of the entry completion part of the
gtk-demo Gtk+ demonstration application, I was able to determine that
the current implementation of accessibility support for 
gtk_entry_completion appears to be broken.

When the user has typed a character such as "t" into the text completion
area, and the list of possible choices has been displayed, typing Insert-F8
in Orca at that point to get a complete list of the accessible component
hierarchy shows that that two item list has the following hierarchy:

  +-name=None role='window' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
    +-name=None role='panel' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
      +-name=None role='filler' state='ENABLED SENSITIVE SHOWING VERTICAL VISIBLE' relations=''
        +-name=None role='scroll pane' state='ENABLED FOCUSABLE SENSITIVE SHOWING VISIBLE' relations=''
          +-name=None role='table' state='ENABLED FOCUSABLE SENSITIVE SHOWING VISIBLE MANAGES_DESCENDANTS' relations=''

Unfortunately that window is at the same component depth as the dialog
for the entry completion.

If you use the Down and Up arrow keys to "select" the entries in this list,
then there are absolutely no accessibility events generated.

Will also tried both my cut-down example and the entry completion example
from gtk-demo with gnopernicus on Ubuntu Edgy Eft, and got the same (broken)
results. Notice spoken or brailled.

My plan now is to generate a simple standalone example that I can use to
attach to a bug against atk/gail on this.

Stay tuned...

Hey Rich, do you see the same behavior with the entry completion in for example the run application dialog that you get with alt+F2?  The reason I ask is that I saw this one working with gnopernicus a couple weeks ago.  I'm wondering if the one in the gtk-demo is broken but real-world applications are working better.  

The entry completion thing in the "Run Application" dialog you get with Alt+F2 is a different beast.  Instead of bringing up a list of possible completions, it actually completes the current line you are typing on, highlighting the text that has been "added".  Note that the braille display in Orca presents this completed text.

I've noticed the braille getting filled in it would also be nice if the speech got updated as well.  Does the autocompletion in evolution look more similar to the one in the gtk-demo or the one in the run dialog?  

I've filed bug #358024 against atk/gail for the underlying problem
that's blocking this one, and adjusted the bug summary to indicate that
we are blocked.

Mike, I'll have a look at the Evolution "text completion" next and comment
back here.

I don't seem to be able to reproduce any kind of auto-completion in
Evolution w.r.t. the To: field. I have the appropriate checkboxes
checked on the Edit->Preferences->Auto-Completion panel. If somebody can
give me a set of steps to reproduce this, I'll look further and if there is
a problem we can file a separate bug on it.

Thanks.

Heads-up to the Orca team - the corresponding GTK+/gail bug here, which is a consequence of new functionality being added to GTK+, looks like it will take significant resourcing to fix, i.e. it's not a simple bugfix but a considerable amount of new code that needs to be written.

The only common place we seem to be running into this is in gtk-demo.  Soo...marking as WONTFIX.  We filed bug 400766 for the more common thing we run into (e.g., autocomplete in Run... dialog) in the real world.