Tab order based on distance from center

[ahmadayubi]

2021-11-24.14-29-04_Trim.mp4

• Add tests / adjust tests for new behavior
• Update popup navigation button functionality
• Prevent features off screen from being tab focused

Closes #385

[ahmadayubi]

@prushforth
Assigning a tab index to features while the map has a taxindex = 0 means the feature gets focused before the map. Is this the intended/accepted behavior?

[prushforth]

Is this the intended/accepted behavior?

My first impression is that the map should always come first. It would be acceptable to skip the controls and go straight to the features, maybe.

[ahmadayubi]

Is this the intended/accepted behavior?

My first impression is that the map should always come first. It would be acceptable to skip the controls and go straight to the features, maybe.

To get this behavior you either have to;

1. set the tabindex of the map to 1 (other side effects)
2. remove the tabindex values when the map is not focused and re-add tabindex only when the map is focused (more computation)

[Malvoz]

I think 2 is the only option, we don't want to break the tab order of elements on people's websites.

[Malvoz]

See also:

• https://adrianroselli.com/2014/11/dont-use-tabindex-greater-than-0.html
• https://dequeuniversity.com/rules/axe/4.0/tabindex
• etc.

[Malvoz]

Would this be compatible with #571?

[ahmadayubi]

Would this be compatible with #571?

No I believe that's getting shelved for now

[prushforth]

Could we establish a private focus order index value that we follow, instead of setting the tabindex > 0? We could handle keystrokes while in a sequence of features and set focus to the next highest/ next lowest private focus order index, perhaps

[prushforth]

I was looking for where @Malvoz mentioned using arrow keys instead of tab keys within a group of features. If we implemented that, we wouldn't be hacking the tabindex, I think.

[Malvoz]

I was looking for where @Malvoz mentioned using arrow keys instead of tab keys within a group of features.

That's #535.

[prushforth]

So, I think we should be using tabindex=-1 and setting a private focus index value that we programmatically use to set the focus on a feature. The private value can be ordered ascending by distance?? Maybe the first feature in the DOM should be tabindex=0 and the rest -1? WDYT?

[ahmadayubi]

That would work, does handling the tab event ourselves have any benefit over adding tabindex when the map is focused and removing it once the map is out of focus?

[prushforth]

Good question, but if we don't change the tabimdex in an antisocial way, it won't matter if our program crashes and can't change it back? Maybe

[prushforth]

Maybe the first feature in the DOM should be tabindex=0 and the rest -1? WDYT?

Maybe the first feature in each layer should be tabindex=0, with the rest =-1...

[ahmadayubi]

2021-11-27.14-37-56.mp4

So I opted to use event handlers as this would also further improvements in the future brought up by @prushforth regarding arrow keys.

All the features in the map are considered rather than on a per layer basis. The highest tabindex value used is now 0, never exceeding this.

The final thing remaining is treating subparts (spans within coordinates) as independent when sorting, currently it treats subparts distance from the center as equal to the distance of the main component.

[ahmadayubi]

The functionality should be reviewed before the tests are updated to reflect the new behavior. So if anyone has time please share any feedback or bugs.

[prushforth]

Looking pretty nice! A couple of things I noticed.

1. for https://maps4html.org/experiments/screenreader/restaurants/ page, if you build your branch and put the dist into a local clone of experiments, it sorts the restaurants very nicely, but if you zoom, you then have to tab twice to get past a marker. If you zoom twice, I think you have to tab 3 times to get past a marker, and the number of times you have to tab grows as you change zoom.

2. in this page with the sorting build in dist https://maps4html.org/experiments/screenreader/closest-restaurants/ if you click the Restaurants button, you'll get the following error:

I'll continue to look for stuff....

[ahmadayubi]

@prushforth The issues you mentioned should be fixed with the latest update, good finds!

[prushforth]

@ahmadayubi the issues seem mostly fixed. I was able to reproduce the first problem:

1. for https://maps4html.org/experiments/screenreader/restaurants/ page, if you build your branch and put the dist into a local clone of experiments, it sorts the restaurants very nicely, but if you zoom, you then have to tab twice to get past a marker. If you zoom twice, I think you have to tab 3 times to get past a marker, and the number of times you have to tab grows as you change zoom.

but not as bad, by first loading the restaurants, then tabbing through them, then zooming in and tabbing a few times, then right-click the restaurants layer entry and press "Zoom to layer". The multiple-tabs-to-get-past-a-marker problem occurs.

[ahmadayubi]

but not as bad, by first loading the restaurants, then tabbing through them, then zooming in and tabbing a few times, then right-click the restaurants layer entry and press "Zoom to layer". The multiple-tabs-to-get-past-a-marker problem occurs.

Hmm okay, it's related to the layer removal, I thought I accounted for it but maybe different map updates run through different removal paths. Will take a look.

[ahmadayubi]

@prushforth Turns out the reason it needed multiple tab presses is because the features are duplicated in the DOM. The bug is related to zoomToLayer in combination with TemplatedFeaturesLayer, where the _pullFeatureFeed is called twice (through the moveend handler) instead of once, not sure why yet.

[prushforth]

I have a feeling that might be due to a change I made during template features processing. So it's an unrelated bug to this.

[Malvoz]

LGTM!

This change on its own would make it difficult for screen reader users to discover that new features have become available after pan/zoom, but it's an important piece of the puzzle. And it all comes together with #636.

[prushforth]

Looks good to me. When tabbing through many features, we do need a way to skip to the end of the sequence so as to not trap the user. This may come into play with feature indexing too. I look forward to implementing arrow key feature navigation as a way of leaving tabs to inter-control/interactive element navigation.

[prushforth]

Boom!