WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: select onchange and WCAG 2.0

for

From: Birkir R. Gunnarsson
Date: Mar 21, 2013 2:41PM

Hi Jon

Others will definitely add insights on this, but here is the W3C page
for SC 3.2.2
http://www.w3.org/TR/UNDERSTANDING-WCAG20/consistent-behavior-unpredictable-change.html

Depending on exactly what happens in your page, just warning the user
may be sufficient.
I am dealing with a similar issue for a vendor, and the vendor's use
of onChange is breaking the Jaws behavior actually (even by opening
the virtual buffer using alt-down arrow I cannot select a choice from
the combobox. Once I've arrowed down once, the first choice is still
selected and activated and I can't see the rest of the options in the
box).
Unfortunately the URL lives inside a test environment, so I cannot post it.
A "dirty solution" though it works, plus the page name amuses me to no
end, can be found here
http://www.mothereffingtoolconfuser.com
(basically just disable the onChange and add a submit button to form
via javascript), but basically I think usually there are not many good
reasons for using onChange, and it can mess with screen readers and
users who are not sure how to use them consistently, plus they can
cause confusion for other users, elderly people, people with cognitivi
impairments etc.).
Looking forward to seeing other responses to this thread myself.
-B

On 3/21/13, Jon Mires < <EMAIL REMOVED> > wrote:
> Hi everyone,
>
> We're helping a client bring their site up to WCAG 2.0 AA conformance.
>
> They have an account selector dropdown (<select> element) that causes a
> page reload (form submit) to display account details for the relevant
> account. This fires onchange - there is no submit button.
>
> I've read the thorough discussion on this list from last year (
> http://webaim.org/discussion/mail_thread?threadG37) as well as some other
> resources.
>
> There seem to be clear usability drawbacks to this method, not the least of
> which is that several browsers require key combinations that users are
> unlikely to be aware of in order to get the onchange event to fire (or not
> fire) when the user wants it to. It seems unreasonable to expect users to
> know these key combinations, and providing descriptions before each
> instance of the interface also seems less than ideal. With some user
> testing, we are also seeing that the onchange event fires inconsistently
> based on the combination of browser / OS / screen reader version people are
> using.
>
> So the main question:
>
> Although we think there are reasons not to use select onchange, are there
> specific reasons using the select onchange interface to submit a form would
> not meet WCAG 2.0 AA?
>
> One of the failure examples (Example 2:
> http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/F36) for 3.2.2 is this
> exact situation, but it is described as:
>
> "This is a example that submits a form when the user selects an option from
> the menu when there is no warning of this behavior in advance."
>
> Does this mean if there is warning of the behavior in advance it would meet
> WCAG 2.0?
>
> Thanks in advance for your insights,
> Jon
> > > >