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!

screenshot of map

  • 6
    Who are your users and what are they trying to achieve? Jul 13, 2023 at 8:05
  • 3
    My users are people searching the digital catalog of a large cultural institute such as a national library using a map based interface. So they are trying to find artifacts related to regions or location, and then access and consume them.
    – GilShalit
    Jul 13, 2023 at 8:16
  • 3
    This is beside the question you're asking, but just as general feedback I find that heatmap to be very noisy. If a single item is enough to make a light blue dot, then what's the point of dark blue existing? I don't know what parameters you control, but it might be good to decrease the magnitude of each individual item. Then a single item could be dark blue, two items in one spot could be light blue, and it could take at least 5 to reach dark red. Jul 13, 2023 at 22:57
  • I tried to open your site and it just spins forever, it doesnt load any data points, it just says Records / Relationships and nothing really loads. So already I am seeing a point where people will just close the site and forget about it. Maybe because I am in the USA and this is served in some other area say Europe / Asia and its just too slow?
    – JonH
    Jul 13, 2023 at 23:13
  • As this is a pilot, it is currently served in Europe and with a low level of resources. Sorry about your experience, thought it seems most people seem to be able to access it.
    – GilShalit
    Jul 15, 2023 at 7:05

3 Answers 3


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.


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.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.