Accessible Maps & Geospatial Content

Yes, when the map delivers information or a function people need. A store locator that is the only way to find a branch, a service-area map, a transit map, or a data map that carries a statistic are all covered by the same accessibility obligations as the rest of the page, and store locators in particular are a recurring subject of ADA web accessibility complaints. The important nuance is how you satisfy the requirement: you rarely have to make the map canvas itself perfect. You have to make the task the map supports achievable without the map, by providing an equivalent path in text and structured controls. A purely decorative map that carries no information can simply be hidden from assistive technology instead.

Build it as a map plus a list, and treat the list as the source of truth. The accessible experience is a labeled search or filter form and a real list or table of results, where each result gives the name, address, distance, and hours as text and offers the same actions as the map, such as a Get directions link and a Select control. Wire the visual map to that list so selecting a result updates the map, never the other way around. A screen reader user or a keyboard-only user should be able to search, read the results, and get directions to a location without ever interacting with the map. When the result count changes, announce it with a live region. The map then becomes a helpful visual enhancement layered on top of an experience that already works without it.

Partly, and not enough to rely on. A Google Maps embed and the major mapping libraries include some keyboard support and some assistive-technology labeling, and that is genuinely better than a hand-built canvas with nothing. But an embed still needs a descriptive title on its iframe so a screen reader announces what the frame contains, and it still does not, on its own, give a non-visual user a usable way to complete your specific task, such as finding the nearest of your twelve stores. You still owe an equivalent non-map path, the list, and you still need to test the keyboard and screen reader experience yourself rather than assuming the provider handled it. Treat the provider's accessibility as a starting point, not a finished job.

Describe what the map communicates in this context, not the fact that it is a map. For a contact page, alt text such as "Map showing Acme Coffee at 5th and Main, two blocks north of Central Station" carries the useful information, whereas "map" carries none. A pin dropped on a tile does not tell a screen reader anything, so the location has to live in the alt text or, better, in real HTML text next to the image. Always pair a static map with the address written out as live text and a Get directions link, which is what most people use anyway. If the map is purely decorative and the address is already in text nearby, give the image an empty alt attribute so it is skipped rather than described redundantly.

Usually no. role="application" tells a screen reader to stop intercepting keystrokes and pass them straight to the widget, which switches off the browse-mode shortcuts blind users rely on to read and navigate. That is only appropriate if you have genuinely implemented full keyboard operation for everything inside the map, panning, zooming, reaching and activating every marker, and reading their information. If you have not, role="application" traps the user in a region where their normal reading commands no longer work and there is nothing to operate in their place. The safer default is to expose the map as a labeled region or group, give it an accessible name, and let the list carry the real interaction. Reach for role="application" only when you have built and tested the keyboard experience to match it.

From text and controls that sit alongside the map, not from the map itself. The address is written out as live HTML text, there is a Get directions link that hands off to the user's preferred maps app, and for a locator there is a list of results with distances and actions. This is the same principle as an image needing a text alternative: whatever the map shows a sighted user, a non-visual user gets the equivalent in a form their assistive technology can read. Designing this way helps far more people than screen reader users. It also serves anyone on a slow connection where the map has not loaded, anyone who prefers to copy an address as text, and search engines indexing your locations.

Every marker a mouse user can click must be a real, focusable, named control, a button or a link, not a div or an image with a click handler bolted on. Its accessible name must identify the place, for example "Acme Coffee, 5th and Main", rather than "marker" or the file name of a pin graphic. The popup or infowindow that opens when a marker is activated behaves like a dialog: move focus into it, let Escape close it, and build its content from real HTML. The harder problem is scale. Hundreds of markers become hundreds of tab stops and a wall of announcements, so cluster them, or better, make the list the primary way people reach a location and keep direct marker interaction as an enhancement rather than the only route.

Treat it as a chart that happens to use geography for its axes. A choropleth, heat map, or bubble map encodes data in color or size across regions, and just like any data visualization its accessible form is the underlying data as a table, region by value, plus a short text summary of the takeaway, for example "Sales were highest in the West region and lowest in the Northeast." Do not make the colored map the only way to read the numbers, and do not rely on color alone to distinguish categories, which fails Use of Color. The accessible charts guide covers the data-table-as-text-alternative pattern in depth, and it applies directly to maps that are really data visualizations.