WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Dynamic Dropdown Form Fields


From: Tony Olivero
Date: Apr 28, 2012 9:03AM

David, Elle:

I've done some similar things on a project in the past. It's a little
jankety, I admit, but it worked (at least for that project). Basically,
create a cvariable that gets assigned a number whenever focus moves off the
first element, put a handler on the element that gets focus in the tab order
next, and if the variable is one, bounce focus back to the field that is
"supposed" to have focus. This solved the issue of simulating a "pause" for
the second field to be inserted into the dom. Once the second field has
focus, you reset the check variable to 0 and the next time the link, or
whatever was the focused element following the initial select has focus,
it's kept because you're not telling it to bounce back off.

Actually, the more I think about it, I used this technique when dynamically
inserting errors and focusing the user on the error text, but the concept is
the same and should work for you.

This may be horrible JS, and possibly people smarter than me will tell you
to run far and fast from my solution, but I thought I'd throw it out there
for consideration.


-----Original Message-----
From: David Ashleydale [mailto: <EMAIL REMOVED> ]
Sent: Friday, April 27, 2012 22:58
To: WebAIM Discussion List
Subject: Re: [WebAIM] Dynamic Dropdown Form Fields

Birkir, I had suggested a solution like that -- putting a button after the
dropdown -- but there are actually a few of these questions at the
beginning of the form. The design team felt that it would be too cumbersome
to make users select then click a button 3 times in a row -- select, click,
select, click, select, click. And for keyboard users it would be: tab,
arrows, tab, enter (times 3).

And, Elle, that's kind of along the lines of what I was thinking. I'm
wondering if there's a way to get the browser to realize that there's a new
element in the tab order right after the Tab key is clicked. Like, maybe we
could force it to pause for 50 microseconds or something. :)


On Friday, April 27, 2012, Birkir R. Gunnarsson wrote:

> If you don't mind Elle, please share your solution with the rest of the
> list.
> What about placing a button after the first dropdown link saying
> (confirm selection). Once user clicks on it it will first populat the
> next field, then move user focus to it (may be a bit clumsy, but it
> could get the job done I suppose)?
> On 4/28/12, Elle < <EMAIL REMOVED> > wrote:
> > David:
> >
> > I know exactly what you're describing, and your guess as to why it's
> > skipping the second (dynamically populated) dropdown is a topic we've
> been
> > working through as well. The choreographed dance of dynamic changes and
> > focus path, that's some crunchy stuff! We're in the wireframe stages
> right
> > now for a similar progressive disclosure scenario in a form.
> >
> > The trick is to get it to occur in sequence, not simultaneously, and to
> > ensure that there's a focus destination as a fallback (perhaps read-only
> > instead of disabled) for the default state of the dynamic dropdown menu.
> I
> > can't remember what steps that we decided on, but I'll ask and send our
> > solution your way in case it helps.
> >
> >
> > Cheers,
> > Elle
> >
> >
> >
> >
> > On Fri, Apr 27, 2012 at 7:42 PM, David Ashleydale
> > < <EMAIL REMOVED> >wrote:
> >
> >> I don't have an example to show right now, but I'll try to describe the
> >> situation that I would like thoughts on.
> >>
> >> Imagine an online form where the first question is a dropdown (select).
> >> The
> >> second question is also a dropdown, but when the page first loads, it
> >> disabled. This is because the options in it are determined dynamically
> >> based on which selection you make in the first dropdown. We tried to
> >> it
> >> up so that after a user makes a selection in the first dropdown, then
> >> they
> >> hit the Tab key, the second dropdown would become enabled and populated
> >> with the correct options, and the user would be taken there.
> >>
> >> However, the way it ended up working was that when a keyboard-only user
> >> hits Tab after using the up and down arrows to make a selection in the
> >> first dropdown, they skip over the second question and are taken to the
> >> next "tabbable" object further down the page; even though the second
> >> dropdown becomes enabled when the user hits Tab (onblur).
> >>
> >> I believe this is because at the time the user hits the Tab key, the
> >> second
> >> dropdown is still disabled. It's kind of a simultaneous issue -- two
> >> things
> >> are trying to happen at the same time: the browser wants to take the
> user
> >> to the next tabbable object and the JavaScript is trying to enable the
> >> formerly disabled dropdown. It seems like the browser has already
> figured
> >> out where it wants to take the user before they've even hit the Tab
> >> so
> >> it doesn't care that we changed the next thing in its path from
> >> to
> >> enabled.
> >>
> >> Hopefully I described the situation sufficiently. Otherwise, I may try
> to
> >> mock something up to show you. But my questions is: what is the best
> >> to
> >> do this in a keyboard accessible way?
> >>
> >> Desired functionality: Form with a dropdown that dynamically enables
> >> adds options to the next dropdown.
> >> Problem: Hitting the Tab key always jumps over the next disabled
> >> dropdown,
> >> even though hitting the Tab key enables it.
> >>
> >> Thanks!
> >> David Ashleydale
> >> > >> > >> > >>
> >
> >
> >
> > --
> > If you want to build a ship, don't drum up the people to gather wood,
> > divide the work, and give orders. Instead, teach them to yearn for the
> vast
> > and endless sea.
> > - Antoine De Saint-Exupéry, The Little Prince
> > > > > > > >
> > > Address