Replace tab-driven feature navigation with arrow keys

[prushforth]

For reference, markers in Google Maps are navigated using arrow keys (though they fail to use appropriate roles for elements per the ARIA design patterns such that users can expect them to be navigated using arrow keys. I may file a bug when I have time to).

Originally posted by @Malvoz in #535 (comment)

[prushforth]

I suggest to use a simple replacement of left-arrow and up-arrow => shift-tab, while down-arrow and right-arrow => tab.

An open question, perhaps for @Malvoz, is how / if to provide audible feedback to screen reader users when the last feature is reached. Similarly when shift-tabbing backwards, would be ideal to give audible feedback for when first feature of sequence is reached.

[ben-lu-uw]

At the moment the linked PR makes it so that the user has to tab in to the features, navigate the features using arrow keys and tab again if they want to reach the controls. Navigating through the features with only arrow keys would "trap them" at the last feature.
Either that behavior could be removed somehow or some feedback to the user could be added as Peter mentioned.

[prushforth]

It's working pretty well. A distinctive sound would be good, but next best would be a localized announcement like "last feature, hit tab to proceed/ shift-tab to go back". I note that Google Maps API just goes back to the first feature.

[prushforth]

We're going to have to figure out how to integrate this with the feature index as the next tab stop.

[Malvoz]

how / if to provide audible feedback to screen reader users when the last feature is reached. Similarly when shift-tabbing backwards, would be ideal to give audible feedback for when first feature of sequence is reached.

I think either:

For up and left: If focus is on the first feature, moves focus to the last feature.
For right and down: If focus is on the last feature, moves focus to the first feature.

similar to the keyboard support for the APG menubar.

Or similar to Grids: don't move the focus.

---

One concern with implementing this: how would screen reader users know they can use arrow keys to navigate features? I think that's where some of the widget roles related to both (e.g.) menubars and grids come into play. But the patterns tend to expect certain roles on the focusable items (due to ARIA requirements) where we'd perhaps want button or link for features. I think focusgroups can help in the future, and perhaps MapML can even specify that features ought to behave as focusgroup items. Text instructions (#267) can also be helpful, or even aria-label similar to the Google Maps site:

Edit: this concern can be solved later, just wanted to note it.

[prushforth]

Or similar to Grids: don't move the focus.

An observation from a quick look at that: page down and page up are used as "accelerators", moving up/down (by analogy forward/backward) some predefined number greater than 1 of table rows, and Ctrl+Home Ctrl+End move to the first/last rows. Not to add work to this PR, but these might also be useful for features. Similarly, for later / another PR.

Edit: I see, as you suggest, that the focusgroup proposal may be how these aspects are implemented in the future.