It's possible this question might be closed as "off topic" since you're asking about implementation details, which are typically asked/answered on stackoverflow.com (using the
accessibility tag like you did with this question).
On a somewhat related topic, see Thomas Logan's blog on equalentry.com regarding accessible google maps. Maps are obviously not the same as image-maps, but the blog still has some good info.
Are your 'headlines' links to other pages? If they're just static text (an
<h2> or similar) then it should not be a tab stop. A tab stop should only occur on elements where the user can perform an action. If the headline is a link, then it should definitely be a tab stop.
As far as the image map itself, the
<area> elements are tab stops by default in firefox, chrome, and ie (I don't have a Mac to test safari), and both nvda and jaws (on the pc) will read the
alt text when the
<area> is tabbed to. The
<area> elements also show up when you display a list of links with the screen reader (if your
<area> has an
href attribute). Those are all good things.
With VoiceOver on iOS, the
<area> elements are not in the normal tab sequence when you swipe left/right. Instead, the entire
<map> is treated as one tab stop. However, if you change your rotor setting to "links", then you can swipe up/down to get to the
<area> elements and the
alt is read.
I imagine a vision-impaired user would navigate with the help of the
tab-key and mouseover.
Note that most visually impaired users will not use mouseover because those users rarely use a mouse.
The first rule of ARIA use is to not use it, so to speak. Try to use native semantic markup first. If you use
<area alt="text">, then you shouldn't need additional ARIA markup. That's good news.
But as mentioned above,
<area> elements are treated as links (when the
<area> has an
href attribute), and when a screen reader user hears "link", they will expect to be navigated to another page or to another location on the same page (in page link). If instead you are displaying a "tooltip" type object, that might be confusing, which I think is the main gist of your question.
I was going to suggest adding
role="button" to your
<area> but the official spec says that the default role of an
<area> is a link and that no other roles are allowed. It makes more sense that the role be a button if you're going to perform an action when the user selects it (such as display more detail), and even though nvda on firefox announces the button correctly, you don't want to have invalid html so don't use
role="button" on an
Another option is to use
aria-expanded. That is valid on an
aria-expanded is valid on links. In a sense, that is sort of what you're doing. You're expanding/collapsing the node in the map to display more information. However, most implementations of this have the newly expanded stuff directly after the link in the DOM so that screen reader users can easily find it. In your case, you can't really put the new text inside the image map.
To get around that, use
aria-owns on the
<area>. Sometimes screen readers use that attribute to help link the two objects together.
Hopefully that's enough to get started.