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.

5 Replies to “OnChange Event on a Select Input/Jump Menu Accessibility Problems”

  1. Hi Paul,

    Thanks for this.

    A related issue is SC 3.2.1 On Focus. Even if a keyboard user manages to avoid the onChange event firing, in many cases, as soon as she presses TAB to move out of the dropdown, the event still fires and loads the new page, which I understand to be a failure of 3.2.1. From what I can tell, this happens in Firefox (Windows and Mac), and there doesn’t seem to be a way around it. Interestingly, in IE, at any rate, after having expanded the dropdown with ALT+DOWN ARROW, one can collapse the dropdown with the ESC key, and then safely press TAB to move on to the next focussable element without firing the event.

    So the explicit action button remains the best advice in all cases 🙂


  2. Hi Paul, thanks for this article. My question is related to the example in this article but is more a question about Success Criterion 3.2.2. If we have a dropdown list where selecting an option with the arrow key *and* then pressing enter reloads the page, are we still going against 3.2.2? Basically trying to understand what ‘change of context’ means — is a page reload on a dropdown item select violating 3.2.2 because a user does not know that a page reload is going to happen when he selects the option? Thanks!


  3. I recently had to deal with auto-go dropdowns. Visually I wasn’t allowed to add a go/submit/doStuff button 🙁

    I already have JS check if interaction is done with a mouse or keyboard (to hide outlines from demanding graphic designers when mice click in some browsers), so I’ve currently got
    – a variable storing what the onload/currently-selected value is
    – a listener for focus, which sets the size to length of the select options. I can’t test on Mac, but Windows and Linux at least now both act the same: they show all the options at once. This doesn’t run if focus was brought by a mouse, letting the default whatever on mouse click do its thing. No graphic designer will discover it so they won’t complain it’s fugly or anything 🙂
    – there’s the code that runs onchange
    – a listener for keyup (or keydown) cancels the onchange listener and checks to see if the user hit enter or tab: if so, another check to see if the new-current value is different from the onload value. If not, do nothing special, otherwise call the onchange code
    – a listener for blur to set the size back to “1”

    I guess I’ll wait for complaints from Mac users to see if this is broken there (can’t afford one), but I’m not expecting any.

  4. Just a note the the ALT+ARROW workaround method does work on Chrome (and Chromium) nowadays, with or without ChromeVox installed. I don’t know when this changed – perhaps it was added to match the IE behaviour at some point…

Leave a Reply

Your email address will not be published. Required fields are marked *