0

Currently, I'm trying to fix some accessibility issues on a single page website. This website consists of various elements (e.g., collapsed menus) in addition to a part where an image-map is used to provide some interactivity to the user. The user can click on multiple elements on the image to show additional text next to it.

I'll try to emulate how a vision-impaired person could interact with the site, using ChromeVox, VoiceOver on Mac and NVDA on Windows.

I do struggle with the right markup to provide the user with an easier way to navigate through the tricky map part. In general, I imagine a vision-impaired user would navigate with the help of the tab-key and mouseover.

The following code is currently triggering the text to display and can be read and focused by assisting tools although it seems like there are wrong attributes included (e.g., title-attribute and empty href-attribute).

<area href="" alt="<alt>" title="<title>" onclick="<onclickmethod>" mapcontent="<mapcontent>" coords="<X>,<Y>,<Z>" shape="circle">

What kind of ARIA attribute, additional description or rearrangement of elements should I consider to help users to navigate through the site without missing out on the additional text?

Accessibility issue with hidden text and map area.

1

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 <area> tag.

Another option is to use aria-expanded. That is valid on an <area> because 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-controls and 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.

<area alt="some description" aria-expanded="false" href="your javascript" aria-owns="id-of-the-text-you-will-unhide" aria-controls="id-of-the-text-you-will-unhide">

  • Thanks a lot for your excellent explanation and your code example. You are right that my description of the way users can navigate through the page is a little bit flawed regarding the tab stops and my expectation of users behavior wrong (although I thought about the various degrees of impairment). I do think about using aria-expanded for the area-tag and will check out the other two you've mentioned. – ITJ Jul 14 '18 at 19:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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