Image & Text Inside a Link Accessibility Issues (Alt & Title Attribute, Expanded/Collapsed State, WAI-ARIA aria-expanded)

This blog post in inspired by the problem where developers have expandable/collapsable content usually in the form of a list of FAQ questions. The question has a +/- graphic that visually indicates to the user to click to expand and see the answer to each FAQ question.

Expanded/Collapsed State

So the accessibility problem is how do you indicate expanding/collapsing content to screen readers?

Another issues sometimes seen is that the developer will have two separate links, the image and the text. These should be combined into one link element for simplicity and to increase the click target area.

Options to Indicate Expanded/Collapsed State

Alt text on the image.
Title attribute on the link, null alt on image.
WAI-ARIA’s aria-expanded on link, null alt.
Visually hidden state text.

Alt on Image

My first thought is alt on the image that dynamically changes from expanded to collapsed using JavaScript. This would be the accessibility standards way of coding it.

Title on Link

Lots of folks like to use the title attribute to indicate things that are not visible in text. I think the title attribute is best used for screen magnification accessibility and possibly cognitive usability improvements. I don’t think the title attribute should be relied upon to communicate information. You’ll see one reason in the test cases.

aria-expanded

Personally I love WAI-ARIA and would love to use it for everything. Indicating state with aria-expanded is another accessibility standards way of doing things. The only problem is browser/AT support.

Visually Hidden Text

And then of course there’s the good old trusty visually hidden text positioned with CSS off the screen so that the text is physically there, just not visible to sighted folks unless they disable CSS. The great thing about visually hidden text is that it behaves the same in all browsers and AT. It’s always read no matter what and read in the order you place it.

Test Cases (external link) Inline Below

Alt on image

ExpandedHello World

AT Behavior

VO reads link Expanded Hello World

  • VoiceOver OSX 10.8.1 – Alt read then link text.
  • NVDA 2012.2.1 – Alt read then link text.
  • JAWS 13.0.924 – Alt read then link text.
  • VoiceOver iOS 5.1.1 – Only link text read, NO alt.

Null alt on image, title on link

Hello World

AT Behavior

VO reads link Hello World
VO reads You are currently on a link, inside of a HTML content. To click this link, press Control-Option-Space. The help tag is: Expanded

  • VoiceOver OSX 10.8.1 – Link text then title is only read as the help tag after a 7 second delay or pressing control+option+shift+h to read help tag (title) manually. User will not know if a help tag is present unless they wait for the 7 second delay or press the help tag command.
  • NVDA 2012.2.1 – Link text then title (in Firefox). Link text, NO title (in IE).
  • JAWS 13.0.924 – Link text then title (in Firefox). Link text, NO title (in IE).
  • VoiceOver iOS 5.1.1 – Only link text read, NO title.

Null alt on image, aria-expanded on link

Hello World

AT Behavior

VO reads expanded link Hello World

  • VoiceOver OSX 10.8.1 – aria-expanded then link text.
  • NVDA 2012.2.1 – Link text then aria-expanded.
  • JAWS 13.0.924 – Link text, NO aria-expanded.
  • VoiceOver iOS 5.1.1 – Only link text read, NO aria-expanded.

Null alt on image, visually hidden state text

Hello World

AT Behavior

VO reads link Hello World Expanded

There is no difference. Visually hidden text is always read in the order it is placed.

Thoughts on Results

The results are not encouraging. I was going to suggest using either alt on the image or visually hidden text but after testing on VoiceOver iOS 5.1.1 alt on an image is not read. You can say that this is all due to browser and AT bugs because the accessibility coding is correct.

Bulletproof Accessibility

The only bulletproof method is using visually hidden text to indicate state and placing that state text in whatever order you choose it to read. I placed the visually hidden state text after the link text in my test case. The decision comes down to what browsers and AT you support and if you want to work around screen reader/browser bugs to provide a more usable solution or if you chose to follow accessibility standards and wait for the AT/browsers to fix themselves.

Your Thoughts?

Hope this helps! Please let me know if you have any questions or feedback.

I will retest this with iOS 6 GM once I get it installed on my iPhone. I think it handles the title attribute differently with a 2 second delay instead of 7 on OS X.

2 Replies to “Image & Text Inside a Link Accessibility Issues (Alt & Title Attribute, Expanded/Collapsed State, WAI-ARIA aria-expanded)”

  1. Hi Paul,
    excellent and thorough analysis, thanks for it.
    The “bulletproof” method works in every case, but it has one problem: the reading order is defined by the code, not the content. As long as you stick with one language, this is a non-issue. But as soon as you localize, for some languages the reading order will be awkward, even nonsensical sometimes. And the content author will have no means to correct it. Dealing with the issue would mean an cumbersome set of rules at the code level, in order to anticipate every situation.
    So I’m afraid we still have to look for the ultimate solution…

  2. Paul, I don’t notice any expanding/collapsing in your example. I usually put the images as a CSS background and toggle with a class (or maybe better, using an ARIA attribute). Title attributes are not dependable unfortunately, and hiding text is not ideal, so it’s probably best to rely on the aria-expanded attribute to relay the state to the AT.

Leave a Reply

Your email address will not be published. Required fields are marked *