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.


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.


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

WordPress Default Theme, Twenty Eleven, Accessibility Plugin

Download Plugin

Injects a few basic accessibility enhancements like fixing outline:0 so keyboard users can see what links are focused and adds a skip link that works in webkit browsers (Chrome, Safari, Mobile Safari). It also bumps up the color contrast to pass WCAG 2.0 AAA and underlines the links to improve usability.

This plugin is very basic. It injects this CSS:

:focus {outline: 2px solid #369;}
#content, #secondary {outline:0 none;}
a {text-decoration:underline; color: #0A5A95;}
#site-description {color: #000000;}

And this JavaScript to fix the Webkit skip link bug:

// Set tabindex on the main and section divs so IE knows they are focusable, and so Webkit browsers will focus() them.
$(‘#content’).attr(‘tabindex’, -1);
$(‘#secondary’).attr(‘tabindex’, -1);
var is_webkit = navigator.userAgent.toLowerCase().indexOf(‘webkit’) > -1;
var is_opera = navigator.userAgent.toLowerCase().indexOf(‘opera’) > -1;

// If Webkit, set focus to it.
var clickAnchor=”#”+this.href.split(‘#’)[1];
if(is_webkit || is_opera)

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!