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