E-mail List Archives
Thread: onchange event in html select
Number of posts in this thread: 4 (In chronological order)
From: adam solomon
Date: Thu, Jan 27 2011 4:15AM
Subject: onchange event in html select
No previous message | Next message →
In this article about accessible event
handling<http://webaim.org/techniques/javascript/eventhandlers>;on
there is an example of an html select whose selected item leads the
user
to a new page. The suggestion to make the select element accessible is to
add a button and have the button click handle the appropriate event. The
reason given is that a keyboard user is unable to navigate through the list
items without causing a select event to occur at each list item, thus
forcing the user to switch pages many times to get to the end of the list.
I may be missing something obvious, yet I was able to navigate through the
list items with the keyboard without causing a selection at each one, both
in IE8 and FireFox. 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?
Thank you in advance for any feedback.
--
adam solomon
linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>;
blogix <http://adam.blogix.co.il/>;
From: Jared Smith
Date: Thu, Jan 27 2011 8:24AM
Subject: Re: onchange event in html select
← Previous message | Next message →
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
WebAIM.org
From: Jason Megginson
Date: Thu, Jan 27 2011 9:06AM
Subject: Re: onchange event in html select
← Previous message | Next message →
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
SSB BART Group
(O):703-637-8964
(C):703-244-7755
-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS 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
WebAIM.org
From: adam solomon
Date: Thu, Jan 27 2011 9:54AM
Subject: Re: onchange event in html select
← Previous message | No next message
Thanks guys for the feedback. As Jason pointed out, I was able to navigate
the items after opening the list and then using the arrow keys even in IE8,
but I forgot to try and tab out, and, alas, it fires the select
event.Firefox, of course, gets even the tab functionality correct.
Thanks for setting me straight.
On Thu, Jan 27, 2011 at 6:05 PM, Jason Megginson <
= EMAIL ADDRESS REMOVED = > wrote:
> 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
> SSB BART Group
> (O):703-637-8964
> (C):703-244-7755
>
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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
> WebAIM.org
>