E-mail List Archives
Re: Accessible Drop-down box without a submit button.
From: Mallory
Date: Dec 12, 2016 6:22AM
- Next message: Mallory: "Re: Require Lead QA for Accessibility testing."
- Previous message: Swift, Daniel P.: "closed caption vs. transcript"
- Next message in Thread: None
- Previous message in Thread: Pierre Hachey: "Re: Accessible Drop-down box without a submit button."
- View all messages in this Thread
We had dropdowns without dedicated buttons to re-order products in a
product list (due to Graphic Designer decisions devs had no control
over). It did cause the page to refresh, however even if it hadn't (even
if the list, which came after this dropdown, merely changed via AJAX), I
would have done what I did anyway:
Originally the first developer had an onchange listener on the dropdown.
Problem is, every browser differs on when that gets run. Are you using
an onchange listener?
IE does it as the user is arrowing around, which they are required to do
as a sighted (or not maybe) keyboarder, simply to *even view the
options*. Because ours caused a page refresh this was simply
unacceptable. Firefox also didn't allow users to see all the options
without arrowing, but only fired onchange once the user blurred, or hit
enter or similar.
Webkit and blink either allowed arrowing or, if you know the keystrokes,
you can make the options pop open. Most of our users were using IE and
Firefox though.
So what we did was:
as the user focussed on the select, the "size" attribute was changed
from "1" to the number of available options. This did push the rest of
the page down but trying to position the options didn't work
cross-browser with all the possible page cutoffs and directions etc
like a real dropdown can.
User was free to arrow around as they pleased without firing onchange as
we set that to null. Whatever had been the current selection was stored
in JavaScript.
Only when the user blurred by tabbing away, and only then if the
selection was different than what had been selected, did the onchange
(now custom) function get run.
As I said, even if there hadn't been a page refresh, I would have done
it this way (of course having a dedicated button would be even better
but that was not allowed). As a frequent keyboarder, I feel I have a
right to see all possible options at my leisure before I do any action
that may change stuff. This would have worked out better if there were
instructions telling users which actions did what, but the Graphics
people were always higher than I on the totem pole.
cheers,
Mallory
On Thu, Dec 8, 2016, at 08:30 PM, Pierre Hachey wrote:
> Thanks JP for feeback
>
>
>
> Sent from my Samsung device
>
>
> -------- Original message --------
> From: JP Jamous < <EMAIL REMOVED> >
> Date: 2016-12-08 1:56 PM (GMT-05:00)
> To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Accessible Drop-down box without a submit button.
>
> Pierre,
>
> I have seen this implemented on other sites including Capital One to pick
> on Nick. Just add a label to the dropdown box that tells the user how to
> interact with the dropdown. That will cover both screen reader users as
> well as keyboard only and users and those with cognitive disabilities.
>
>
- Next message: Mallory: "Re: Require Lead QA for Accessibility testing."
- Previous message: Swift, Daniel P.: "closed caption vs. transcript"
- Next message in Thread: None
- Previous message in Thread: Pierre Hachey: "Re: Accessible Drop-down box without a submit button."
- View all messages in this Thread