Is tabbing the best/only accessibility solution on a data heavy map UI?

Question

We are building a digital library search tool for which we need to implement accessibility standards.

The map is VERY data dense (you can experience it here and I have included a screen capture below). At low zoom level, the points are presented as a heat map; when zooming in, detailed locations are shown. But there are always many points.

Is tabbing between the points the only way to increase accessibility? It seems that when there are hundreds of points on screen this would not be usable.

Any innovative ideas will be welcome!

Answer 1

A common practice in GIS applications is to provide a results table alongside the map. If it's a simple list it might be on the left-hand side, like in Google Maps. If it's a data-heavy grid it will usually be under the map. The table is synced with the map, so that switching between items on the table switches the selection on the map and vice versa.

The abundance of data points is typically addressed by providing advanced querying capabilities, and/or dashboards, providing you with an overview of a specific region on the map, or of a set of query results.

In your specific case it seems that geographical search is only one of the ways in which your users might want to search for information, and probably not the most effective one, because the information itself is not of a geographical nature. So alternative mechanisms need to be provided, letting users limit the scope of their search.

If you look at sites like yellow pages, classifieds, real estate listings, travel sites like Booking etc., you might find a lot of appropriate references for approaching this kind of challenges.

Answer 2

tab is one way to navigate with the keyboard but when you have a "composite" widget, the keyboard navigation recommendation is:

Authors SHOULD ensure that a composite widget exists as a single navigation stop within the larger navigation system of the web page. Once the composite widget has focus, authors SHOULD provide a separate navigation mechanism for users to navigate to elements that are descendants or owned children of the composite element.

What constitutes a single tabstop on your map might depend on the zoom level. In your screenshot, perhaps each country should be a tabstop, and once you get to a country, then you can arrow (left and right, or up and down) to individual points.

If you zoom into a specific country, then individual states or provinces might be a tabstop. If you zoom into a state or province, then cities might be a tabstop.

You can also implement other keyboard shortcuts for navigation. A general key on the PC for navigating between areas is F6. Not sure if that could be mapped to your application but in theory F6 (or some other key combination) could be used to navigate between larger areas on the map.

A couple side notes:

• The list of filters along the left are currently not keyboard focusable. If you're trying to reduce the amount of times a user has to tab, then the group of filters could be one tabstop and then up/down arrow between them. Kind of like how a radio group works.
• Your info 'i' button displays a dialog but the dialog is added at the end of the DOM and the focus is not moved into the dialog. That means a user has to tab through the entire page until they can move the focus inside the dialog. (A savvy user might figure out they can move their focus to the address bar [alt+d] and then tab backwards to quickly get into the dialog.) Follow the dialog pattern.
• Also in the info dialog, the X-close button to dismiss the dialog doesn't have a label. Your 'next' and 'prev' buttons in the "Record Types" have an aria-label, so nice job with that, but the X-close needs an aria-label too.

Answer 3

Tabbing between points may be a good literal use of standard key combinations, but with this much data density you may give a better experience by using Tab to switch between regions (search, map, legend, etc.) and using arrow keys to move between items within that region. That's more like what you'd get with a data grid.

It seems you're (appropriately) worried about the density of the map data. You may do well grouping the points further, like another zoomed-out level. The top level could be something like a grid, existing state borders (this seems to be approximately Europe), or density groups (kernel density comes to mind, although it seems as if you've already implemented something very much along these lines). Allow users to move between those, then provide a zoom in/out key set. Grids like these generally lend well to zooming in and out also, so you could still provide reasonable movement at any zoom level. Some of these options may be difficult to generate good polygons for.

The suggestion of creating a queryable data table may also be a good solution to some things, but that could have varying effects on accessibility. I like being able to query the data set for any map I use but I also know many people who will leave a page if they see too much data table up front.