Keyboard accessibility improvements to Input component's dropdown area.

[glastonbridge]

Demo build: https://dropdown-key-input-capture.review-pxt.pages.dev/

This PR attempts to make keyboard accessibility closer to the WAI-ARIA standard for combo boxes when an input provides a dropdown. Specifically:

• Down arrow opens the dropdown, where it exists
• The dropdown is given focus and is navigable by arrow keys, space and enter to select, and escape to abort
• There is only one active tab stop, removing the need for a separate stop to display the menu as that is nonstandard

How to test

1. Enable the Accessible Blocks plugin and add a Sound Effect block (example project)
2. Open the sound effect block using the keyboard and navigate to "Duration (ms)"
3. Use down arrow to open the dropdown, space or enter to select, escape to leave the dropdown without selecting
4. Observe it also works with mouse, or a combination of keyboard and mouse
5. Observe that escape key and enter key have now got their usual functions in blockly (NB: escape will not close the Sound Effect editor while a HTML input, such as the collapsed "Duration (ms)" field, is selected. This is part of Blockly's implementation and is not solved here).
6. Observe that the behaviour is correct on multiple openings of the dropdown and/or editor

Implementation concerns

Some of the accessible keys for a dropdown are intercepted by Blockly at a high level, specifically escape and enter, and these make accessible navigation problematic. I have implemented a lifecycle operation, to be enabled only for the lifetime of the visible dropdown, which blocks those keyboard shortcuts then reasserts them on close.

This is the best solution that I could find using the information I had, but it is unsatisfyingly complex and I welcome better ways to achieve this.

Whatever approach we use here will need to be extended to the Dropdown component too.

[riknoll]

currently, react-common has no dependency on blockly and i'd like to keep it that way. react-common is shared between several of makecode's various webapps many of which have nothing to do with blockly at all.

is there a way we can make this a little more generic? could we create a wrapper component in webapp/ that handles the blockly side of things maybe?

[glastonbridge]

is there a way we can make this a little more generic? could we create a wrapper component in webapp/ that handles the blockly side of things maybe?

Hi @riknoll, thanks for your feedback, I appreciate the benefits of good separation of concerns. I've made an attempt to implement a wrapper component as you suggested, have a look at the latest commit and see what you think.

[riknoll]

LGTM! just remove the import

[riknoll]

@glastonbridge looks like a linting issue! you can run gulp lint locally to check it