WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: onchange event in html select


From: Jason Megginson
Date: Jan 27, 2011 9:06AM

On Thursday, January 27, 2011 10:22 AM, Jared Smith wrote:

> Is it 'technically' accessible? >Yes. Is it functionally very friendly
and > usable to many users? No.

I think this is a great statement. Users may be able to open the html
select list with "alt+down arrow" and navigate (inspect) the options with
the arrow keys. A user can cancel a selection with the "Esc" key avoiding
the event from being invoked. However if a user presses "Tab" with the
list opened the event will fire.

Some users may not know to navigate the lists in this manner. We also
suggest that an adjacent button (sans onchange event) is the most
accessible and usable option.

Jason Megginson

-----Original Message-----
[mailto: <EMAIL REMOVED> ] On Behalf Of Jared Smith
Sent: Thursday, January 27, 2011 10:22 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] onchange event in html select

On Thu, Jan 27, 2011 at 4:15 AM, adam solomon wrote:

> I know that traditionally we have always heard that a
> button must be provided with the select in such a case, yet is it really
> inaccessible without the button?

You must have something enabled that is overriding IE's default
behavior. Do you have JavaScript enabled?

In my installations with IE8, simply arrowing up or down through the
controls at http://webaim.org/techniques/javascript/eventhandlers#onchange
results in the page automatically changing. Additionally, if you
navigate the control with the keyboard in any browser and then hit the
tab key the page unexpectedly changes. Clicking on it in IE and
scrolling with a mouse wheel also results in an unexpected change.
Clicking on it with the mouse and simply selecting an option results
in a potentially unexpected change.

In all of these situations the page changes location in a non-standard
way - via changing or blurring a select menu rather than a form
submission. Any time your page changes location or context via
something other than a link or form submission, it has potential to
introduce confusion and frustration. Is it 'technically' accessible?
Yes. Is it functionally very friendly and usable to many users? No.

Jared Smith