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.

OnChange Event on a Select Input/Jump Menu Accessibility Problems

On Input Success Criterion 3.2.2

WCAG 2.0’s On Input Success Criterion 3.2.2 states that:

“Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)”

Details here: Understanding Success Criterion 3.2.2 | Understanding WCAG 2.0

Here is my go-to example for this accessibility problem in action: iCITA: onChange Event Example.

Inaccessible Select control shown in Internet Explorer. View Example link to see in action.

Affected Browsers

The only browsers affected by this issue are versions of Internet Explorer (the most popular browsers on the internet when combined) and Chrome. So it’s obviously a problem for Windows users. This problem does not affect mouse users, only keyboard-only/screen reader users. Mac users are also not affected.

Inaccessible Select control shown in Safari on OS X. View Example link to see in action.

Basically the issue is that many times a developer will have a select input menu with different options, often called a jump menu or drop-down menu, that is tied to the onChange JavaScript event. In the iCITA: onChange Event Example there is a list of links to W3C specifications in the select. A keyboard user would enter the select then use the UP/DOWN ARROW keys to make a choice. The problem is that as soon as the DOWN ARROW is pressed the JS onChange event fires and sends the user to the first option causing a change of context. Go try it yourself in IE or Chrome on Windows. Now try it in Firefox or any browser on a Mac. Firefox makes up for the developers accessibility error by preventing the onChange event from firing until the user’s focus leaves the select. Browsers on the Mac actually open the list of options as if you were clicking the select with a mouse. Browsers on Windows do not open the list of options when using keyboard navigation.

ALT+UP/DOWN ARROW Workaround

There is a workaround for IE and Firefox on Windows to open the select’s options with the keyboard, the command is ALT+UP/DOWN ARROW. So this is great because a keyboard/screen reader user can now open the list of options and navigate between each, read them all, and then finally press ENTER or TAB to activate their selection which then fires the onChange event. Now the only problem is that this does not work on Chrome :(.

Inaccessible Select control shown in Internet Explorer after pressing ALT+DOWN ARROW. View Example link to see in action.

Use onClick on a “Go” Button Instead

The typical solution for this onChange on a select accessibility issue is to not tie the onChange even to the select but rather tie an onClick event to a “Go” button directly after the select. This way any type of user can cycle through all the options in the select then TAB to the “Go” button and activate it to choose their selection. You can see this in action on the Accessible version of the iCITA: onChange Event Example. The problem with this approach is that many designers and developers do not want an extra button or extra step. They prefer the “less is more” approach. G80: Providing a submit button to initiate a change of context | Techniques for WCAG 2.0

Accessible Select control with Go button shown in Chrome on Windows. View Example link to see in action.

Option to Programmatically Associate Change of Context Explanation & Instructions

WCAG does offer an alternative way to meet SC 3.2.2 On Input by placing instructions before the select explaining what will happen. Since most typical web users have no idea about the ALT+DOWN/UP ARROW command this would be a great place to include those instructions. It is also recommend to programmatically associate the instructions with the form control. This could be done using WAI-ARIA’s aria-describedby attribute or for a more bulletproof approach simply placing the instructions in the select’s label. See the details for this approach here: G13: Describing what will happen before a change to a form control that causes a change of context to occur is made | Techniques for WCAG 2.0

Bulletproof Accessible Solution: onClick on a “Go” Button

Providing instructions explaining the change of context and how to activate the select without firing the onChange event right away is good and all BUT this does nothing to help out Chrome on Windows users who cannot use ALT+UP/DOWN ARROW. Therefore, the only truly bulletproof accessible solution to the onChange event on Select inputs is to not use it and instead use the onClick on a “Go” button. Sure you can pass WCAG 2.0 SC 3.2.2 On Change with the instructions approach and you can blame the problem on Chrome but are you really providing a universally accessible solution with that approach? No. So it’s up to you to decide.

Feedback?

I’d love to get some feedback in the comments so fire away! You can find me on Twitter as well @pauljadam.