Autocomplete: Announce autocomplete correctly in all ATs. Fixes #9631.

[dylanb]

Autocomplete: default functionality does not announce the suggestions correctly

I know that this pull request s not complete but wanted to open this so we could discuss an issue I have encountered during implementation.

I saw the example with categories and modified the implementation to announce the category correctly.

In trying to implement the unit tests for this, could not find an existing unit test. I also could not find any documentation on the "items" option (for the Menu widget) that is being used in the categories example. I also could not find evidence that this is standard functionality.

We have three options:

1. I could leave the implementation as is thereby formalizing the categories further as a "feature" and add a unit test for this,
2. I could implement a callback option for obtaining the full accessible name of an item, or
3. I could do both

Thoughts @scottgonzalez

[scottgonzalez]

Categories are completely custom; the autocomplete plugin shouldn't know anything about it. Would it make sense to use an ARIA attribute, such as aria-label and if the menu item has that, use it instead of the value?

[dylanb]

Good idea. Implemented!

[dylanb]

@scottgonzalez this PR is ready for review now. From an architecture perspective, I think a more comprehensive rewrite would make the usability slightly better. Right now, because the focus stays on the input and the input is updating all the time, you end up with multiple announcements. But it is usable on all platforms.

It could be improved by moving the focus into the menu on the first down arrow - like the way the new datepicker works - and then simply relying on the menu announcements. The input could still be updated as it currently is without the duplicate announcements. If you are ok with that disruptive a change, I could do that. Thoughts?

[scottgonzalez]

We use Firefox's Awesome Bar as a UX reference, and that keeps focus in the input. Moving focus would mean that we'd need to proxy all keypresses (other than up/down) back to the input. It's something we can consider, but we'd need to do extensive testing to make sure it behaves properly. If you think it would be a big improvement, you can certainly send another PR and we can compare the two implementations.

[jzaefferer]

Proxying keypresses sounds like a sure way to madness. Consider how I type the second character of my name on Mac US keyboard: alt + u, o - how would you possibly proxy that? I'm sure it gets much worse with IME (for Japanese).

The code changes as-is look good to me. Haven't yet done testing beyond that.

[dylanb]

This code here

    var keyCode = e.charCode || e.which || e.keyCode,
        keyString = String.fromCharCode(keyCode).toLowerCase();

Will pick the international characters up properly if the keyboard sends them as a single keystroke (as is the case when you change your keyboard to the German layout and press the : (colon) key)

However, I do not know what happens with Japanese and if there is no way to get this code to work with that, then that is a big problem.

if you are good with this PR, then lets close the issue.

[jzaefferer]

In the underlying ticket you wrote:

A better solution would be to not update the input field until the user has made a choice and user aria-live to announce the selections as the user traverses through them.

I don't see that implemented here, instead you mostly updated how the live region is used. Can you confirm that this PR fully addresses the original issue? It seems to me like there is some room between constantly updating the input and moving the focus elsewhere.

[dylanb]

This PR fully addresses the issue.

If you do not update the input field then you will encounter a problem with JAWS where multiple down arrow keypresses simultaneously cause JAWS to pop out of forms mode and stop accepting further user arrow keys as inputs to the input element. So what you would have to do is to implement the solution where the focus really moves onto the menu itself and then keystrokes are interpreted there. This would however suffer from the multi-key input problem you mentioned above.

[jzaefferer]

Did another code review, and tested with NVDA, JAWS and VoiceOver. Merged as-is, while updating the commit message to our new format.

Thanks @dylanb! Hoping to see more PRs like this for other widgets.

[jessebeach]

This is really clever, using aria-relevant="additions" and just appending nodes to the liveRegion rather than replacing the text content completely.

[dylanb]

Thanks! :-)