spun off bug 559766: (In reply to James Teh [:Jamie] from comment #20) > (In reply to alexander surkov from comment #19) > > You don't mean twice down arrow before NVDA says something, right? i.e. > > first down arrow open popup, second down arrow selects first item? > Ah. So that's what's happening. If this is the case, the autocomplete list > should probably gain focus on the first press of down/up arrow to make it > clear that keyboard focus has moved there. This would make the experience > similar to context menus. context menus don't take a focus but they are subject of menupopup_start/end events which are supposedly processed by you. That's the difference I can see between autocomplete list and context menu. On the another hand autocompletes are closer to comboboxes which aren't subject of menupopup_start/end events. Maybe they should be.

(In reply to alexander surkov from comment #0) > context menus don't take a focus but they are subject of menupopup_start/end > events which are supposedly processed by you. We treat menupopupStart/End events as focus events. However, this may not be true for all ATs. > That's the difference I can > see between autocomplete list and context menu. On the another hand > autocompletes are closer to comboboxes which aren't subject of > menupopup_start/end events. Maybe they should be. The difference between an autocomplete list and a combo box is that the combo box has focus before it is expanded. Once it is expanded, the first item immediately gains focus. In the case of autocomplete lists, nothing ever gets focus until the first item is selected, so the user has no idea that they have entered an autocomplete list.

autocomplete popup is a list so there's no popup accessible which is usually target of menupopup_start/end events and that makes autocompletes close to comboboxes. The problem should be valid for editable comboboxes which are different from autocompletes by role (not taking account slightly different behavior). It appears we have two options: 1) fire menupopup_start/end for editable comboboxes and autocompletes 2) fire expanded state change events when autocomplete popup gets shown/hidden. Jamie, you're up for 1)?

(In reply to alexander surkov from comment #2) > autocomplete popup is a list so there's no popup accessible which is usually > target of menupopup_start/end events and that makes autocompletes close to > comboboxes. Not quite. With a combo box, the first item is selected automatically when you expand it, so there's never any point where the user doesn't know what has happened. With autocompletes, the user is left wondering what has happened on the first press. > 1) fire menupopup_start/end for editable comboboxes and autocompletes This doesn't really make sense. As I noted, for us, a menuPopupStart is the same as focus, so it would achieve nothing. > 2) fire expanded state change events when autocomplete popup gets > shown/hidden. I thought of this one too and was going to suggest it. It still isn't quite right to me, as the user doesn't know they're now in the list. However, at least the user would be notified that the autocomplete has expanded, so they'll come to understand that the next arrow key will move to a list item. Out of these two options, I'll take option 2.

(In reply to James Teh [:Jamie] from comment #3) > (In reply to alexander surkov from comment #2) > > autocomplete popup is a list so there's no popup accessible which is usually > > target of menupopup_start/end events and that makes autocompletes close to > > comboboxes. > Not quite. With a combo box, the first item is selected automatically when > you expand it, so there's never any point where the user doesn't know what > has happened. With autocompletes, the user is left wondering what has > happened on the first press. except editable comboboxes > > 1) fire menupopup_start/end for editable comboboxes and autocompletes > This doesn't really make sense. As I noted, for us, a menuPopupStart is the > same as focus, so it would achieve nothing. I didn't understand why it doesn't make sense > > 2) fire expanded state change events when autocomplete popup gets > > shown/hidden. > I thought of this one too and was going to suggest it. It still isn't quite > right to me, as the user doesn't know they're now in the list. However, at > least the user would be notified that the autocomplete has expanded, so > they'll come to understand that the next arrow key will move to a list item. > Out of these two options, I'll take option 2. visually focus stays on autocomplete textfield always, so that if AT users are notified about autocomplete list gets open/hidden then it sounds what we want. Treating menupopup_start/end as a focus makes you inconsistent with focused state and focus methods which might be not desired. However the 2nd approach has an implementation issue because autocomplete and autocomplete list may live in different documents and different processes (case of e10s enabled build), so we should be ready for crossprocess communications to fire expanded state change. That's something I would try to avoid.

We discussed this on IRC. I'm commenting here to record the findings. :) (In reply to alexander surkov from comment #4) > > > 1) fire menupopup_start/end for editable comboboxes and autocompletes > > This doesn't really make sense. As I noted, for us, a menuPopupStart is the > > same as focus, so it would achieve nothing. > I didn't understand why it doesn't make sense Sorry. I thought you meant firing menuPopupStart on the editable text field, not the autocomplete list. Firing it on the list makes more sense. However, I didn't realise that the popup actually appears while the user is typing. Now that I know this, firing menuPopupStart on the list would be a very bad idea because it would throw the screen reader focus out of the editable text field, which is bad if the user wants to continue typing. In short, this option is a definite no. > > > 2) fire expanded state change events when autocomplete popup gets > > > shown/hidden. > However the 2nd approach has an implementation issue because autocomplete > and autocomplete list may live in different documents and different > processes (case of e10s enabled build), so we should be ready for > crossprocess communications to fire expanded state change. That's something > I would try to avoid. This option is the best option we can come up with and seems to satisfy the requirements. The user would be notified that the autocomplete has expanded, but could continue typing otherwise undisturbed if not interested. However, given the difficulty of implementing this, in my opinion, it is extremely low priority. The current situation is usable once you understand how it works and I think there are far more important issues to solve right now.

marking as blocking bug 688480 which should be a fix for this bug.