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.

SXSW 2013 Panel Picker Voting Accessibility Problems

Accessibility Matters to Me

This is the second year I’ve proposed a panel at SXSW Interactive on accessibility. Both years on mobile accessibility which is the area I find most exciting. I recorded a video using the VoiceOver screen reader on my iPad to use as supporting materials in the hope that my panel will be accepted. I also took the extra effort to add closed captions to the YouTube video to make it accessible to the deaf.

iAccessibility – Mobile Freedom for All

My proposed panel is titled iAccessibility – Mobile Freedom for All. You can read all the details, watch the video, and hopefully vote for me here. I also linked to my past presentation, iAccessibility: iPhones & iPads Mobile Freedom for All, given at many accessibility conferences. This is what my panel will be based on but it will be thoroughly updated with new content and tweaked before presenting.

Blind Users Cannot Vote for a Panel

I was very excited to promote my panel on Twitter and Facebook when voting began. Disappointingly, when voting I attempted to use the VoiceOver screen reader on OS X and discovered that voting was impossible. Below I will document the accessibility problems with SXSW’s Panel Picker voting process. I plan to include the code fixes that will make this accessible and contact SXSW to ask that they fix this. I’ll edit this post with new information as it comes in.

What Exactly are the Accessibility Problems?

  • Incorrect reading order places voting buttons at the very bottom of the page.
  • Voting buttons cannot be focused with the keyboard. You cannot TAB to these buttons and activate with the keyboard.
  • Use of non-native HTML links or buttons that are not keyboard accessible by default.
  • The Facebook, Twitter, and LinkedIn share buttons have no alt attribute and cannot be focused with the keyboard.
  • The thumbs up & thumbs down voting buttons have no text alternative. These two glyphs, ☝ & ☟, do not make sense to a screen reader.
  • Voting is not possible when using VoiceOver on a Mac, iPhone, or iPad.
  • Voting with voice control software, Dragon NaturallySpeaking, is also not possible (or easily possible).
  • Voting button hover style does not match focus style. (Focus is not possible anyway.)

Reading Order

Disabling CSS shows incorrect reading order with voting buttons at the very bottom of the page.

Vote Buttons with CSS disabled

Even though visually the voting buttons are in the top-left corner of the page, in the source code order (which matches reading order) the voting buttons are at the very bottom, right before the footer. The developer used CSS positioning to move the vote buttons to the top left.

No Keyboard Focus, TAB Key will Not Reach Buttons

The buttons are not coded semantically. They are glyphs wrapped in spans, wrapped in list items, inside a unordered list. Though you can make this type of code look however you want it is not natively keyboard focusable HTML elements.

Here we see the code inspected with the Chrome developer tools.

List elements code in Chrome developer tools

Here we see VoiceOver on OS X announcing them as “list 2 items”.
VoiceOver output of list 2 items

If I run an accessibility audit in Chrome Canary’s developer tools we see a warning that “Elements with on click handlers must be focusable”.

Chrome Canary's accessibility audit tool

So these buttons work fine with the mouse, onclick, but they do not work with the keyboard because they are not focusable.

No Text Alternative to the Button Glyphs

Here you see that I am able to get VoiceOver to focus on the thumbs-up button and you see that it says clickable but using VoiceOver to activate this button does not work. It is only possible to vote using the mouse. Of course that does not help if you are blind and cannot see the screen.

VoiceOver output says ☝ clickable

What you don’t see in the VoiceOver caption panel where is says ☝ clickable is that VoiceOver actually speaks “Up Pointing Index clickable”. That really makes no sense though and requires a text alternative like “Vote Up” or “Vote Down”.

Share Buttons Have No Alt Attribute or Keyboard Focus

There are the same problems with the sharing buttons, no text alternative & no keyboard access. So in addition to the fact that my blind friends cannot vote for my panel, they also cannot use the sharing buttons to spread the word about promoting accessibility at SXSW Interactive.

VoiceOver’s output of “25 clickable” makes no sense to a blind user.

VoiceOver output of sharing buttons 25 clickable

Button Hover does not Match Focus

Though focus is not possible currently, this should also be documented.

Vote Up button turns black on hover

Moving Forward

I plan to contact SXSW shortly and send them the link to this post. I also plan to update it with actual code fix recommendations. Hopefully SXSW will be happy to receive the feedback and make the needed improvements. I’ll keep this post updated with new details.

I may also upload a video showing how it will not work on the iPad were you can also hear the problems with VoiceOver’s audio output.

Please help me promote accessibility at a mainstream technology conference like SXSW Interactive by voting for my panel and sharing this blog post with your friends.

Please leave a comment here or find me @pauljadam on Twitter. Thanks!