MDN autocomplete accessibility: aria-live region doesn't update consistently, unexpected context change, focus handling on Esc

[patrickhlauke]

Posted these as a comment on the https://hacks.mozilla.org/2021/08/mdns-autocomplete-search blog post, but perhaps more productive doing it here...

Screen reader behaviour could be improved a tad. The a11y-status-message container is not always updated correctly – try typing in “test” letter by letter; on the first letter, it announces that 10 results are available; any subsequent letters that are typed in (and change the number of results) don’t update the message container/make any announcement. Other words are fine though … e.g. “axes” announces the different numbers of results as you go along. It’s a bit flakey.

Also, for keyboard users in general, once one of the suggestions is highlighted (after reaching it with cursor keys), but the user decides to bail out by using “Tab”, the result is triggered anyway as if they had pressed enter. It should just close the autocomplete results and move focus along.

Pressing Esc to close the autocomplete popup leads to focus being lost. While browsers generally error correct for this, it’s not reliable. Focus should be explicitly moved to the search input again.

[peterbe]

Love it! Thanks for taking the time.

I actually don't know what the "a11y-status-message container" is. How do I see this?

Pressing Tab when you've hovered over a search result really shouldn't be interpreted as a click on that search result. You're right. Definitely a bug. I don't see us doing anything specific in our code with Tab. Perhaps it's a bug in Downshift (useCombobox) or how we use it. Hmm...

Regarding Esc causing a full blur trigger is our fault. I created: https://github.com/mdn/yari/pull/4416

[patrickhlauke]

I actually don't know what the "a11y-status-message container" is. How do I see this?

it's injected dynamically into the page the first time you hover over or focus the combobox

messages that get announced by screen readers are dynamically added, and then removed, here (if you keep an eye on the element in devtools, you'll see it updates briefly after each keystroke - in the case of "axis" - or not - in the case of "test"). there must be something borked in the logic that decides when to send messages.

[patrickhlauke]

Pressing Esc to close the autocomplete popup leads to focus being lost. While browsers generally error correct for this, it’s not reliable. Focus should be explicitly moved to the search input again.

belatedly, an additional consideration: Esc also clears whatever the user had entered so far in the search box. This is unexpected/frustrating (a user may just want to type a search term in, hits Esc to move the autocomplete out of the way, but wants to carry on typing out the search term to do a traditional search). Suggest the value of the search box input should not be blanked/emptied when the user hits Esc (though this may cause additional considerations - should the box reappear if the user carries on typing? or should it now remain closed until next time the user sets focus back into the input, and optionally re-open it explicitly if the user does something like pressing cursor down? the latter sounds like the most robust)

[peterbe]

an additional consideration: Esc also clears whatever the user had entered so far in the search box.

I can not reproduce that.

https://user-images.githubusercontent.com/26739/129629190-85ca598d-8647-4fd7-b4f7-2b5d3c745790.mov

[patrickhlauke]

Interesting. It doesn't clear it in Firefox, but it does in Chrome and Edge.

[peterbe]

Confirmed! ...in Chrome :(

[caugner]

Esc also clears whatever the user had entered so far in the search box.

FWIW Esc now clears both in Chrome and Firefox.

[caugner]

Hi @patrickhlauke, would you mind checking for us if this is still an issue? Thank you! 🙏

[patrickhlauke]

tested briefly now with latest Chrome and NVDA:

• when first entering a term, NVDA announces the first result that is highlighted, with "1 of 11" or similar
• if the user then types more letters to narrow the results, the suggestions get updated, and NVDA announces the new first result with "1 of 2" or similar (though occasionally, it behaves a bit flakily, and doesn't announce anything with speech ... though I see it in the NVDA Speech Viewer; this is likely a quirk in NVDA)
• using Tab to "bail out" of using a suggested result now works as expected, and doesn't automatically load whatever was highlighted.

These parts seem to work properly now.

However, these aspects are still not quite right:

• Esc clears the search, but it then still loses focus altogether (document.activeElement goes back to body) - while NVDA/browsers error-correct for this, some other combinations (like Chrome/Jaws) really don't like this and bounce the user all the way back to the start of the page
• arguably, it's surprising that Esc not only closes the suggestions, but also clears the search input

[caugner]

Thank you for your quick response @patrickhlauke, much appreciated! 🙌