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.