960241 - Tabbing into a list with selectable children should cause the list to emit an accessible state-changed:focused event

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[Joanmarie Diggs]

Attachment: accessible-event listener: listbox-focus.py

Steps to reproduce:
1. Launch the attached accessible-event listener in a terminal
2. Launch the test case in the browser
3. Tab to move focus into the list

Expected result: The control with the selectable children (i.e. the list itself) would emit an initial object:state-changed:focused event.

Actual result: The list item child is the only one to emit the focus event.

Comment 1

[Joanmarie Diggs]

Attachment: test case: listbox.html

Comment 2

[alexander :surkov (:asurkov)]

(In reply to Joanmarie Diggs from comment #0)

> Expected result: The control with the selectable children (i.e. the list
> itself) would emit an initial object:state-changed:focused event.
> 
> Actual result: The list item child is the only one to emit the focus event.

the behavior (i.e items receive the focus) is wanted by Windows screen readers. What makes Orca exceptions different?

Comment 3

[Joanmarie Diggs]

I'm wondering what makes Windows screen readers different.

The definition of ATK_STATE_FOCUSED is "Indicates this object currently has the keyboard focus". And the list claims to be focusable (via ATK_STATE_FOCUSABLE), but seems to never get (claim) focus. So either the FOCUSABLE state is wrong (please, please don't tell me that ;) ) or the fact that the list never claims focus is wrong.

From a practical point of view: Each time the selected item changes in a <insert widget with selectable children here>, Orca wants to know two things:

1. Should that change be presented?
2. If so, should the parent widget (along with its label, number of items, etc.) also be presented?

The answer to question 1 depends on whether or not that parent widget has keyboard focus. Consider an email client with mailboxes on the left and messages on the right. Changing the selected mailbox on the left likely causes selection changes in the messages on the right. But the changes on the right shouldn't be presented if the focused list is the one on the left. Another example might be a chat list. If the highlighted buddy in the buddy list signs off, the selected item will presumably change. But if the parent list is not focused, presenting that change is probably not desired. Long way of saying: Being able to look at a given list for STATE_FOCUSED is *extremely* helpful in determining whether or not to present a selection change.

The answer to question 2 depends on what had focus before. If focus used to not be in the list and now is in the list, then we want to present the additional information about the list itself. At the moment, for Gecko listboxes, every time there is a selection change or a state change for a list item, Orca needs to look at the previously focused item and its associated ancestry. If the focusable list would simply claim STATE_FOCUSED when it was entered, Orca wouldn't have to do that extra checking.

Comment 4

[Joanmarie Diggs]

One more quick thing (sorry for being spammy): I don't care if the items claim focus after the list claims focus. I have no problem with that. I just want the list to claim focus first.

Comment 5

[alexander :surkov (:asurkov)]

(In reply to Joanmarie Diggs from comment #3)
> I'm wondering what makes Windows screen readers different.

Windows screen readers operate with keyboard (user) focus (not DOM focus), so if the user is on menu/list item then menu/list is considered having the focus.

> The definition of ATK_STATE_FOCUSED is "Indicates this object currently has
> the keyboard focus". And the list claims to be focusable (via
> ATK_STATE_FOCUSABLE), but seems to never get (claim) focus.

Not really never, it may receive the focus when no items.

> So either the
> FOCUSABLE state is wrong (please, please don't tell me that ;) ) or the fact
> that the list never claims focus is wrong.

not wrong on Windows, they use to differentiate lists and listboxes on Windows, since MSAA doesn't provide separate roles for them. It's rather feature, focusable but doesn't get focused.

Items also claim they are focusable and they receive focus.

> From a practical point of view: Each time the selected item changes in a
> <insert widget with selectable children here>, Orca wants to know two things:
> 
> 1. Should that change be presented?
> 2. If so, should the parent widget (along with its label, number of items,
> etc.) also be presented?
> 
> The answer to question 1 depends on whether or not that parent widget has
> keyboard focus.

if an item gets focus event then the change should be presented, if an item gets selection change event then probably not

> The answer to question 2 depends on what had focus before. If focus used to
> not be in the list and now is in the list, then we want to present the
> additional information about the list itself. At the moment, for Gecko
> listboxes, every time there is a selection change or a state change for a
> list item, Orca needs to look at the previously focused item and its
> associated ancestry. If the focusable list would simply claim STATE_FOCUSED
> when it was entered, Orca wouldn't have to do that extra checking.

not sure how Windows screen readers do here but they manage it somehow. I can't change the behavior on Windows and I would try to avoid to make the change for ATK since it's sort of big difference. What do WebKit does?

Comment 6

[Joanmarie Diggs]

WebKit does the expected thing:

Initial Tab into list:

  object:state-changed:focused(1, 0, 0)
	source: [list | ]
	host_application: [application | WebKitWebProcess]

As I arrow amongst items, I get both state-changed:focused for the list item, and the expected selection-changed events. In other words, both behaviors are pretty much the same, but for WebKit we get the initial focused event for the listbox.

As for making the change for ATK, why can't you do an initial focused state-change for the list box? It has STATE_FOCUSABLE, it is a focusable widget (right?), and it gains focus when you Tab into it (right?).

Comment 7

[alexander :surkov (:asurkov)]

(In reply to Joanmarie Diggs from comment #6)
> WebKit does the expected thing:
> 
> Initial Tab into list:
> 
>   object:state-changed:focused(1, 0, 0)
> 	source: [list | ]
> 	host_application: [application | WebKitWebProcess]

Don't you want to announce the current item (having keyboard focus) when you navigate to the listbox? If you want then how can you figure out what item is current if item is not a focus target for the first time?

> As I arrow amongst items, I get both state-changed:focused for the list
> item, and the expected selection-changed events. In other words, both
> behaviors are pretty much the same, but for WebKit we get the initial
> focused event for the listbox.

I'm curious how they do on Windows

> As for making the change for ATK, why can't you do an initial focused
> state-change for the list box? It has STATE_FOCUSABLE, it is a focusable
> widget (right?), and it gains focus when you Tab into it (right?).

technically yes but that likely means I need a change on crossplaform layer and thus make somehow two focuses existing the same time, ATK part is simple enough mapping of internal layer where the all logic lives.

Comment 8

[Joanmarie Diggs]

(In reply to alexander :surkov from comment #7)

> Don't you want to announce the current item (having keyboard focus) when you
> navigate to the listbox? 

Yes.

> If you want then how can you figure out what item
> is current if item is not a focus target for the first time?

1. The accessible selection interface
2. As I stated in comment 4, I'm fine with an immediate focus event for the list item

The follow-up to that and my comment 4 is, emitting focused-changed events for list items should not remove STATE_FOCUSED from the parent list box.

But I am not asking you to stop emitting state-changed:focused on list items. WebKit does it, Windows wants it, and in the case of a multiselect list box it makes sense because selection does not necessarily correspond to focus. ALL I am asking is an initial state-changed:focused on the parent taking place prior to the initial state-changed:focused on the list item.

Could Windows just ignore that first event?
 
> technically yes but that likely means I need a change on crossplaform layer
> and thus make somehow two focuses existing the same time, ATK part is simple
> enough mapping of internal layer where the all logic lives.

On the one hand, I feel bad asking for platform-specific differences. But on the other hand, I don't think it's good to try to force a one-size-fits-all solution on Gecko. Platforms are just too different....

Comment 9

[alexander :surkov (:asurkov)]

(In reply to Joanmarie Diggs from comment #8)
> (In reply to alexander :surkov from comment #7)

> > If you want then how can you figure out what item
> > is current if item is not a focus target for the first time?
> 
> 1. The accessible selection interface

it doesn't help because the current item is not selected

> 2. As I stated in comment 4, I'm fine with an immediate focus event for the
> list item
> The follow-up to that and my comment 4 is, emitting focused-changed events
> for list items should not remove STATE_FOCUSED from the parent list box.

it means that two accessibles (listbox and its current item) have STATE_FOCUSED simultaneously, right? it may have some unexpected consequences, for example, focused child may return a listbox rather than list item

> But I am not asking you to stop emitting state-changed:focused on list
> items. WebKit does it, Windows wants it, and in the case of a multiselect
> list box it makes sense because selection does not necessarily correspond to
> focus. ALL I am asking is an initial state-changed:focused on the parent
> taking place prior to the initial state-changed:focused on the list item.

> Could Windows just ignore that first event?

I think we always can invent something on Gecko side. Alternatively would it be good to know how Windows AT handle that? Perhaps there's some simple trick.

> > technically yes but that likely means I need a change on crossplaform layer
> > and thus make somehow two focuses existing the same time, ATK part is simple
> > enough mapping of internal layer where the all logic lives.
> 
> On the one hand, I feel bad asking for platform-specific differences. But on
> the other hand, I don't think it's good to try to force a one-size-fits-all
> solution on Gecko. Platforms are just too different....

that's right, we do platform tricks, when we don't have other option. But I'm getting happier when we are able to keep ATK and IA2 AT closer in their assumptions/needs.