This has severe accessibility issues which are fortunately fairly easily remedied. The short explanation of the problem: users of screen readers and others like them will be unable to use this at all.<p>Your map is essentially an imagemap, implemented with SVG rather than a raster image and <map>. But this draws attention to two important things about imagemaps that aren’t implemented: indication of what you’re hovering on, and keyboard accessibility.<p>With an imagemap, each area is a link, so at the very least you’ll see the href in the status bar of your browser in desktop browsers; and you can do better by adding a tooltip with the title attribute.<p>The HTML title attribute translates to the SVG <title> element, which should be the first child of the element it applies to:<p><pre><code> <path …>
<title>…</title>
</path>
</code></pre>
Secondly, each state needs to be focusable so that keyboard users and screen readers can click on them.<p>One way of doing that is to just slap tabindex="0" on each path, and slap a keydown handler on it to detect Enter. That’s an improvement and would make it tolerably accessible, but it’s not the <i>best</i> solution.<p>The best solution is to make each state <i>actually</i> a link. Wrap each <path> element with <a xlink:href="…"> (remember this is the SVG anchor element, not the HTML one, hence xlink:href. On the latest browsers you can use href instead, but Safari has only supported this for 16 months and Firefox for three years, so xlink:href is safest).<p>The eventual markup should be something like this:<p><pre><code> <svg>
<a xlink:href="#AK">
<title>Alaska</title>
<path d="…"/>
</a>
<a xlink:href="#CA">
<title>California</title>
<path d="…"/>
</a>
…
</svg>
</code></pre>
And then start actually using the fragment for routing. This has the additional benefit of allowing sharing more precise links. The fragment used for routing should probably not match real document IDs, or else the document would be inclined to scroll underneath you; or else you could use a real one and just negate that. But if the link target is not a real element, add a link click handler that focuses the infobox, so that screen readers get pushed to the right place rather than remaining in the middle of the map.<p>Probably best also to order the paths alphabetically so that screen reader and keyboard users go through them in order.<p>Consider adding :focus and :hover styling too (e.g. change stroke colour, increase stroke-width, adjust fill-opacity, add a filter that tweaks the colour).