Assign tabindex=n in ascending order of distance of feature from map centre

[prushforth]

It seems that having to tab through every feature in a map viewport could be a burden especially for blind users. One of the benefits of maps is that sighted users are able to immediately see the relevance of spatial phenomena relative to locations, often the map centre point.

There should be a way to improve the usability of maps with features for blind users, and I think this might help with one aspect of that, by reducing the amount of tabbing they have to do to get relevant info.

When a server is involved, it could sort features naturally in that order before serializing the document, without having to set the tab order. But it should also be a function that can be requested on the client, perhaps with a user preference. Sorting these things can be an intensive process so it might not be something the viewer should do on every request, but it seems reasonable to allow a user to make it their default.

Unsure if there's a UCR issue for this, not at first glance anyway.

[ahmadayubi]

Would a blind person be expecting to go from "center" of map outwards or would they expect to go in the document order? The idea of center seems more so visual unless the blind user has an idea of long, lat positions but I don't think most ordinary people do (at least I don't). I feel like this maybe more so valuable to a sighted keyboard user than a blind user, not sure.

[Malvoz]

Screen readers announce content in the DOM order and users mostly expect the focus order to match that reading order (creating a disconnect between the two is generally considered bad practice), so I think serializing the document without having to set the tab order would be optimal.

[prushforth]

This seems like a server side concern, if screen readers are going to always read in document order, the document would have to have a relevance order by the time it hits the user, so not actually a concern of the client.

OTOH, maybe there should be a way (user preference, perhaps) to tell screen readers to read the content in some spatial relevance order, knowing that it is dealing with spatial data. Sighted users can assess spatial relevance visually on maps, a UA should be able to help with that, I think.

[Malvoz]

This seems like a server side concern

Yes.

Sighted users can assess spatial relevance visually on maps

While it may be hard to draw a line right now between what may be expected from screen readers (e.g. potential settings/preferences/keyboard shortcuts) in relation to navigating maps and the things that should be built into maps directly, we still have to polyfill that, whether through keyboard shortcuts, preferences, etc. However, being able to assess spatial relevance is very important in maps so it's a bit worrisome to think that that's not the default, and only available to some users after checking a preference setting.

#396 specifically attempts to achieve this for unsighted users as well. Perhaps importantly through the same mode of operation, such that when a sighted user is navigating a map (with a screen reader in use) next to an unsighted user (and vice-versa) it'll make sense to both.

[Malvoz]

#385 (comment):

the document would have to have a relevance order by the time it hits the user

While I don't believe that pursuing this would allow unsighted users to accurately see the relevance of spatial phenomena relative to locations (as #396 could), there are still benefits to creating a logical focus order (whether "logical" in maps is from the map center, or from top to bottom and from left to right in English, etc. as in documents) because currently (and I think this is true for basically every map on the web) the focus order of markers/features is random and not logical.

[prushforth]

I think we need to take action on this item. The focus order of features in the DOM is the first step in how non-visual users will be able to get some benefit from 2D maps, imho. So I think we need to have a preference that allows the user to request the browser (our mapml-extension) to sort features in ascending order of distance from map center focus ordering, with the sort function executing on moveend. @ahmadayubi are you willing to start this off?

[ahmadayubi]

@prushforth how would this ordering work in relation to features being panned to center on focus? I'm not sure if it'd be possible to have both as it would make some features unreachable.

For example:

The 3 features that are selected create a loop, excluding the green feature.

[prushforth]

I don't follow. When you zoom to a feature, I would use the new map centre as the seed and sort features by distance from that location. We could start by using a simplistic feature representation i.e. just a point, even just the first coordinate in the feature, improve the algorithm from there.

[prushforth]

The sorting would have to be within a layer, mind you

[ahmadayubi]

You still run into the same issue, consider this.

• You focus the red feature (the red feature is at the center of the map now)
• You recalculate distance, blue is the closest
• You focus blue feature (blue feature is at the center of the map now)
• You recalculate distance, purple is the closest
• You focus purple (purple feature is at the center of the map now)
• You recalculate distance, blue is the closest
• ...
• in the end the green feature is never reached, because it's never the closest to any other feature
• you just cycle through red, blue, purple, then vise versa

[ahmadayubi]

In other words the sequence would go:

red -> blue -> purple, then purple -> blue -> red, and it repeats, excluding green entirely

[prushforth]

oh I see what you're getting at

[prushforth]

doesn't work if you move the map on focus