E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 12 (In chronological order)

From: Isabel Holdsworth
Date: Fri, Mar 01 2019 7:49AM
Subject: Listboxes that update content
No previous message | Next message →

Hi all,

I have a listbox that updates the main page content when the selected
option is changed.

It's easy using a mouse: the box expands on hover and the user can
click the option that corresponds to the content they want to see.

But how about keyboard users? I'd rather not use the old "Go" button
keyboard solution, as it's beginning to feel a little bit archaic IMO,
and it doesn't fit in with our design.

Are there any alternative mechanisms for enabling keyboard users to
scroll through a list of items without selecting them, and to select
an option only when they choose to?

One of the listboxes we currently use updates the page content on
blur, but I'm not convinced this is OK. Perhaps it would be more
acceptable if pressing ESC reverted back to the original selection?

I'd really appreciate your thoughts on this.

Cheers, Isabel

From: Steve Green
Date: Fri, Mar 01 2019 8:19AM
Subject: Re: Listboxes that update content
← Previous message | Next message →

The list of options in native comboboxes can be opened by pressing Alt+DownArrow. You can then use the arrow keys to scroll through the options without selecting them. This has been standard behaviour for at least 20 years, if not forever.

However, in the 15 years we have been doing user testing I have almost never seen anyone do this, so I expect the level of awareness is pretty low even among people who use keyboard navigation all the time.

Steve Green
Managing Director
Test Partners Ltd

From: glen walker
Date: Fri, Mar 01 2019 8:21AM
Subject: Re: Listboxes that update content
← Previous message | Next message →

Sounds like you already have a custom component. So you hover with the
mouse and the list expands (like a flyout menu) and when you click with the
mouse, the page updates?

For a keyboard user, does the list expand when the object receives focus or
do they have to press enter/space first? If you're using aria-expanded, I
would expect the latter. You could easily allow the arrow keys to move the
focus within the object and then require enter/space to select the item.
In fact, that's essentially how a real menu works.

I don't think I'd update anything on blur. I'd expect the blur to be a
cancel (similar to the slider discussion). Tab to the object, enter/space
to expand, arrow up/down, tab off to cancel.

From: glen walker
Date: Fri, Mar 01 2019 8:25AM
Subject: Re: Listboxes that update content
← Previous message | Next message →

I do this all the time (alt+down), but strangely enough I think the
behavior changed in firefox recently. Now I have to press space on the
<select> to get the dropdown list to appear. Alt+down still works in
chrome and ie.

On Fri, Mar 1, 2019 at 8:19 AM Steve Green < = EMAIL ADDRESS REMOVED = >
wrote:

> The list of options in native comboboxes can be opened by pressing
> Alt+DownArrow. You can then use the arrow keys to scroll through the
> options without selecting them. This has been standard behaviour for at
> least 20 years, if not forever.
>

From: Isabel Holdsworth
Date: Fri, Mar 01 2019 8:38AM
Subject: Re: Listboxes that update content
← Previous message | Next message →

Thanks Steve and Glen.

Sometimes Alt+DownArrow opens the list, sometimes Space or Enter.
Would it be reasonable for keyboard users to know they'd need to press
an extra key for the change to occur? From the small amount of user
testing I've done, users tend not to be aware of this.

But if I provide an alternative mechanism (arrow buttons to the left
and right of the list), perhaps this is enough.

Cheers, Isabel

On 01/03/2019, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> I do this all the time (alt+down), but strangely enough I think the
> behavior changed in firefox recently. Now I have to press space on the
> <select> to get the dropdown list to appear. Alt+down still works in
> chrome and ie.
>
> On Fri, Mar 1, 2019 at 8:19 AM Steve Green < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> The list of options in native comboboxes can be opened by pressing
>> Alt+DownArrow. You can then use the arrow keys to scroll through the
>> options without selecting them. This has been standard behaviour for at
>> least 20 years, if not forever.
>>
> > > > >

From: Jonathan Avila
Date: Fri, Mar 01 2019 9:01AM
Subject: Re: Listboxes that update content
← Previous message | Next message →

I've used update on blur before with select boxes and would not expect tabbing out of a select box to reset my result -- I'd want tabbing out to keep the item I had selected with the arrow keys. For select boxes use of the arrow keys generally moves focus and selection together. Menus are different where enter is expected to select because up/down arrows only focus something but not select it. So for a menu, I would expect on blur to cancel the menu.

Jonathan

From: Mallory
Date: Sat, Mar 02 2019 5:30AM
Subject: Re: Listboxes that update content
← Previous message | Next message →

Users may get confused about custom listboxes by way of how browsers are different in real native selects:
IE fires onChange as users arrow through the options! (though it's the only one who does I believe)
The others vary on whether blur is cancelling thing or an onChange thing (or whether blur is an onChange but only if the last-focussed value is different from the previous value, which I think was Firefox).

If you want users to select with enter key then one way you could show them that blur is not the way is, post-blur, show what the selectedIndex (or whatever your listbox version of selectedIndex is) was. That is, people can go back and see what's currently selected.

_m

On Fri, Mar 1, 2019, at 5:01 PM, Jonathan Avila wrote:
> I've used update on blur before with select boxes and would not expect
> tabbing out of a select box to reset my result -- I'd want tabbing out
> to keep the item I had selected with the arrow keys. For select boxes
> use of the arrow keys generally moves focus and selection together.
> Menus are different where enter is expected to select because up/down
> arrows only focus something but not select it. So for a menu, I would
> expect on blur to cancel the menu.
>
> Jonathan
>
>

From: Birkir R. Gunnarsson
Date: Sat, Mar 02 2019 10:55AM
Subject: Re: Listboxes that update content
← Previous message | Next message →

Given total freedom I'd just recommend against a listbox as a
navigation mechanism.
I think a much more effective mechanism is just a simple accordion
list of in-page links, they are fit for purpose, easy to code, and
behave consistently within the browser.
If, instead of navigating you basically load screens you can use
buttons, using aria-pressed="true" to indicate the currently active
button.
I'm not sure if a listbox breaks WCAG 3.2.2 (does the content reload
constitute a change of context as you interact with the listbox).
It depends on the specifics of how the page works.
Of course we're often not at the liberty of suggesting a drastic
re-design, we have to do the best with the current design of the page.
I think the old "go" button is not a bad idea, also have the listbox
remember the current choice, make it the default when user navigates
to the listbox.
I've implemented a completely ARIA compliant navigation megamenu
(which I was proud of but users found confusing), then a set of menu
buttons, I've ended up settling on recommending accordions, because
their much simpler to code and less confusing for users, a win win.


On 3/2/19, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
> Users may get confused about custom listboxes by way of how browsers are
> different in real native selects:
> IE fires onChange as users arrow through the options! (though it's the only
> one who does I believe)
> The others vary on whether blur is cancelling thing or an onChange thing (or
> whether blur is an onChange but only if the last-focussed value is different
> from the previous value, which I think was Firefox).
>
> If you want users to select with enter key then one way you could show them
> that blur is not the way is, post-blur, show what the selectedIndex (or
> whatever your listbox version of selectedIndex is) was. That is, people can
> go back and see what's currently selected.
>
> _m
>
> On Fri, Mar 1, 2019, at 5:01 PM, Jonathan Avila wrote:
>> I've used update on blur before with select boxes and would not expect
>> tabbing out of a select box to reset my result -- I'd want tabbing out
>> to keep the item I had selected with the arrow keys. For select boxes
>> use of the arrow keys generally moves focus and selection together.
>> Menus are different where enter is expected to select because up/down
>> arrows only focus something but not select it. So for a menu, I would
>> expect on blur to cancel the menu.
>>
>> Jonathan
>>
>>

From: Isabel Holdsworth
Date: Mon, Mar 04 2019 4:34AM
Subject: Re: Listboxes that update content
← Previous message | Next message →

Thanks Mallory, Birkir. Yes, the listbox landscape is confusing.

I'm trying to come up with a mechanism that's easier for keyboard
users to navigate than our current one.

Currently we have a bar that consists of buttons with question numbers
on them. I've only recently realised that there can be scores of
questions in one section of a test, and keyboard users would have to
tab through all of these before being able to answer the current
question. So I thought encapsulating them into a listbox with
first-letter navigation and Prev/Next arrow buttons to each side would
be a good work-around. But when I began exploring the dynamics of
listbox operation using a keyboard, I started to question my own
wisdom.

But I can't think of any other way of minimising the number of tabs
required and still offering equivalent keyboard functionality.

We don't design the tests, so we can't instruct authors to chop them
up into smaller sections or anything sensible like that. We need to
work with what we've got and make the experience as keyboard-friendly
as we can.

Is there a widget other than a listbox that I could use? I can't think
of one off-hand.

Cheers, Isabel

On 02/03/2019, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> Given total freedom I'd just recommend against a listbox as a
> navigation mechanism.
> I think a much more effective mechanism is just a simple accordion
> list of in-page links, they are fit for purpose, easy to code, and
> behave consistently within the browser.
> If, instead of navigating you basically load screens you can use
> buttons, using aria-pressed="true" to indicate the currently active
> button.
> I'm not sure if a listbox breaks WCAG 3.2.2 (does the content reload
> constitute a change of context as you interact with the listbox).
> It depends on the specifics of how the page works.
> Of course we're often not at the liberty of suggesting a drastic
> re-design, we have to do the best with the current design of the page.
> I think the old "go" button is not a bad idea, also have the listbox
> remember the current choice, make it the default when user navigates
> to the listbox.
> I've implemented a completely ARIA compliant navigation megamenu
> (which I was proud of but users found confusing), then a set of menu
> buttons, I've ended up settling on recommending accordions, because
> their much simpler to code and less confusing for users, a win win.
>
>
> On 3/2/19, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
>> Users may get confused about custom listboxes by way of how browsers are
>> different in real native selects:
>> IE fires onChange as users arrow through the options! (though it's the
>> only
>> one who does I believe)
>> The others vary on whether blur is cancelling thing or an onChange thing
>> (or
>> whether blur is an onChange but only if the last-focussed value is
>> different
>> from the previous value, which I think was Firefox).
>>
>> If you want users to select with enter key then one way you could show
>> them
>> that blur is not the way is, post-blur, show what the selectedIndex (or
>> whatever your listbox version of selectedIndex is) was. That is, people
>> can
>> go back and see what's currently selected.
>>
>> _m
>>
>> On Fri, Mar 1, 2019, at 5:01 PM, Jonathan Avila wrote:
>>> I've used update on blur before with select boxes and would not expect
>>> tabbing out of a select box to reset my result -- I'd want tabbing out
>>> to keep the item I had selected with the arrow keys. For select boxes
>>> use of the arrow keys generally moves focus and selection together.
>>> Menus are different where enter is expected to select because up/down
>>> arrows only focus something but not select it. So for a menu, I would
>>> expect on blur to cancel the menu.
>>>
>>> Jonathan
>>>
>>>

From: Birkir R. Gunnarsson
Date: Tue, Mar 05 2019 5:10AM
Subject: Re: Listboxes that update content
← Previous message | Next message →

Ok, in that scenario, why not a listbox with the label "select
question", the options are the numbers of individual quesstion and a
"go to question" button.
Supplement that with previous and next buttons and I think you are in
decent shape. I've seen these types of select widgets on websites and
I find them pretty intuitive.

I guess this is already what you have in mind ;) I just think the "go"
button, though old fashioned can make a big difference here.
You can hide it visually if it bothers designers, hide it like a skip
link so it becomes visible on keyboard focus.


On 3/4/19, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks Mallory, Birkir. Yes, the listbox landscape is confusing.
>
> I'm trying to come up with a mechanism that's easier for keyboard
> users to navigate than our current one.
>
> Currently we have a bar that consists of buttons with question numbers
> on them. I've only recently realised that there can be scores of
> questions in one section of a test, and keyboard users would have to
> tab through all of these before being able to answer the current
> question. So I thought encapsulating them into a listbox with
> first-letter navigation and Prev/Next arrow buttons to each side would
> be a good work-around. But when I began exploring the dynamics of
> listbox operation using a keyboard, I started to question my own
> wisdom.
>
> But I can't think of any other way of minimising the number of tabs
> required and still offering equivalent keyboard functionality.
>
> We don't design the tests, so we can't instruct authors to chop them
> up into smaller sections or anything sensible like that. We need to
> work with what we've got and make the experience as keyboard-friendly
> as we can.
>
> Is there a widget other than a listbox that I could use? I can't think
> of one off-hand.
>
> Cheers, Isabel
>
> On 02/03/2019, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>> Given total freedom I'd just recommend against a listbox as a
>> navigation mechanism.
>> I think a much more effective mechanism is just a simple accordion
>> list of in-page links, they are fit for purpose, easy to code, and
>> behave consistently within the browser.
>> If, instead of navigating you basically load screens you can use
>> buttons, using aria-pressed="true" to indicate the currently active
>> button.
>> I'm not sure if a listbox breaks WCAG 3.2.2 (does the content reload
>> constitute a change of context as you interact with the listbox).
>> It depends on the specifics of how the page works.
>> Of course we're often not at the liberty of suggesting a drastic
>> re-design, we have to do the best with the current design of the page.
>> I think the old "go" button is not a bad idea, also have the listbox
>> remember the current choice, make it the default when user navigates
>> to the listbox.
>> I've implemented a completely ARIA compliant navigation megamenu
>> (which I was proud of but users found confusing), then a set of menu
>> buttons, I've ended up settling on recommending accordions, because
>> their much simpler to code and less confusing for users, a win win.
>>
>>
>> On 3/2/19, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
>>> Users may get confused about custom listboxes by way of how browsers are
>>> different in real native selects:
>>> IE fires onChange as users arrow through the options! (though it's the
>>> only
>>> one who does I believe)
>>> The others vary on whether blur is cancelling thing or an onChange thing
>>> (or
>>> whether blur is an onChange but only if the last-focussed value is
>>> different
>>> from the previous value, which I think was Firefox).
>>>
>>> If you want users to select with enter key then one way you could show
>>> them
>>> that blur is not the way is, post-blur, show what the selectedIndex (or
>>> whatever your listbox version of selectedIndex is) was. That is, people
>>> can
>>> go back and see what's currently selected.
>>>
>>> _m
>>>
>>> On Fri, Mar 1, 2019, at 5:01 PM, Jonathan Avila wrote:
>>>> I've used update on blur before with select boxes and would not expect
>>>> tabbing out of a select box to reset my result -- I'd want tabbing out
>>>> to keep the item I had selected with the arrow keys. For select boxes
>>>> use of the arrow keys generally moves focus and selection together.
>>>> Menus are different where enter is expected to select because up/down
>>>> arrows only focus something but not select it. So for a menu, I would
>>>> expect on blur to cancel the menu.
>>>>
>>>> Jonathan
>>>>
>>>>

From: Isabel Holdsworth
Date: Wed, Mar 06 2019 4:45AM
Subject: Re: Listboxes that update content
← Previous message | Next message →

Thanks Birkir.

I've thought about using a hidden "Go" button, but I prefer not to use
hidden elements that are only displayed on focus as they don't work
for speech input users. I think our design people and/or our client
base would push back if the "Go" button was visible, as the proposed
design is a nice symmetrical widget that has a listbox in the middle
with single then double arrows to each side. The single arrows move to
the previous and next question, and the double arrows move to the
first and last. It looks good. Our accessibility people are part of
the design team, and the widget needs to look good and behave nicely
for us all to be happy bunnies.

Currently, pressing Space or Enter triggers the expanded/collapsed
state of the list, but we could leave it collapsed and cause arrow
keys to change the selection and Space or Enter to show the selected
question.

Cheers, Isabel

On 05/03/2019, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> Ok, in that scenario, why not a listbox with the label "select
> question", the options are the numbers of individual quesstion and a
> "go to question" button.
> Supplement that with previous and next buttons and I think you are in
> decent shape. I've seen these types of select widgets on websites and
> I find them pretty intuitive.
>
> I guess this is already what you have in mind ;) I just think the "go"
> button, though old fashioned can make a big difference here.
> You can hide it visually if it bothers designers, hide it like a skip
> link so it becomes visible on keyboard focus.
>
>
> On 3/4/19, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
>> Thanks Mallory, Birkir. Yes, the listbox landscape is confusing.
>>
>> I'm trying to come up with a mechanism that's easier for keyboard
>> users to navigate than our current one.
>>
>> Currently we have a bar that consists of buttons with question numbers
>> on them. I've only recently realised that there can be scores of
>> questions in one section of a test, and keyboard users would have to
>> tab through all of these before being able to answer the current
>> question. So I thought encapsulating them into a listbox with
>> first-letter navigation and Prev/Next arrow buttons to each side would
>> be a good work-around. But when I began exploring the dynamics of
>> listbox operation using a keyboard, I started to question my own
>> wisdom.
>>
>> But I can't think of any other way of minimising the number of tabs
>> required and still offering equivalent keyboard functionality.
>>
>> We don't design the tests, so we can't instruct authors to chop them
>> up into smaller sections or anything sensible like that. We need to
>> work with what we've got and make the experience as keyboard-friendly
>> as we can.
>>
>> Is there a widget other than a listbox that I could use? I can't think
>> of one off-hand.
>>
>> Cheers, Isabel
>>
>> On 02/03/2019, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>>> Given total freedom I'd just recommend against a listbox as a
>>> navigation mechanism.
>>> I think a much more effective mechanism is just a simple accordion
>>> list of in-page links, they are fit for purpose, easy to code, and
>>> behave consistently within the browser.
>>> If, instead of navigating you basically load screens you can use
>>> buttons, using aria-pressed="true" to indicate the currently active
>>> button.
>>> I'm not sure if a listbox breaks WCAG 3.2.2 (does the content reload
>>> constitute a change of context as you interact with the listbox).
>>> It depends on the specifics of how the page works.
>>> Of course we're often not at the liberty of suggesting a drastic
>>> re-design, we have to do the best with the current design of the page.
>>> I think the old "go" button is not a bad idea, also have the listbox
>>> remember the current choice, make it the default when user navigates
>>> to the listbox.
>>> I've implemented a completely ARIA compliant navigation megamenu
>>> (which I was proud of but users found confusing), then a set of menu
>>> buttons, I've ended up settling on recommending accordions, because
>>> their much simpler to code and less confusing for users, a win win.
>>>
>>>
>>> On 3/2/19, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
>>>> Users may get confused about custom listboxes by way of how browsers
>>>> are
>>>> different in real native selects:
>>>> IE fires onChange as users arrow through the options! (though it's the
>>>> only
>>>> one who does I believe)
>>>> The others vary on whether blur is cancelling thing or an onChange
>>>> thing
>>>> (or
>>>> whether blur is an onChange but only if the last-focussed value is
>>>> different
>>>> from the previous value, which I think was Firefox).
>>>>
>>>> If you want users to select with enter key then one way you could show
>>>> them
>>>> that blur is not the way is, post-blur, show what the selectedIndex (or
>>>> whatever your listbox version of selectedIndex is) was. That is, people
>>>> can
>>>> go back and see what's currently selected.
>>>>
>>>> _m
>>>>
>>>> On Fri, Mar 1, 2019, at 5:01 PM, Jonathan Avila wrote:
>>>>> I've used update on blur before with select boxes and would not expect
>>>>> tabbing out of a select box to reset my result -- I'd want tabbing out
>>>>> to keep the item I had selected with the arrow keys. For select boxes
>>>>> use of the arrow keys generally moves focus and selection together.
>>>>> Menus are different where enter is expected to select because up/down
>>>>> arrows only focus something but not select it. So for a menu, I would
>>>>> expect on blur to cancel the menu.
>>>>>
>>>>> Jonathan
>>>>>
>>>>>

From: Isabel Holdsworth
Date: Wed, Mar 06 2019 4:47AM
Subject: Re: Listboxes that update content
← Previous message | No next message

On 06/03/2019, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
> Thanks Birkir.
>
> I've thought about using a hidden "Go" button, but I prefer not to use
> hidden elements that are only displayed on focus as they don't work
> for speech input users. I think our design people and/or our client
> base would push back if the "Go" button was visible, as the proposed
> design is a nice symmetrical widget that has a listbox in the middle
> with single then double arrows to each side. The single arrows move to
> the previous and next question, and the double arrows move to the
> first and last. It looks good. Our accessibility people are part of
> the design team, and the widget needs to look good and behave nicely
> for us all to be happy bunnies.
>
> Currently, pressing Space or Enter triggers the expanded/collapsed
> state of the list, but we could leave it collapsed and cause arrow
> keys to change the selection and Space or Enter to show the selected
> question.
>
> Cheers, Isabel
>
> On 05/03/2019, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>> Ok, in that scenario, why not a listbox with the label "select
>> question", the options are the numbers of individual quesstion and a
>> "go to question" button.
>> Supplement that with previous and next buttons and I think you are in
>> decent shape. I've seen these types of select widgets on websites and
>> I find them pretty intuitive.
>>
>> I guess this is already what you have in mind ;) I just think the "go"
>> button, though old fashioned can make a big difference here.
>> You can hide it visually if it bothers designers, hide it like a skip
>> link so it becomes visible on keyboard focus.
>>
>>
>> On 3/4/19, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
>>> Thanks Mallory, Birkir. Yes, the listbox landscape is confusing.
>>>
>>> I'm trying to come up with a mechanism that's easier for keyboard
>>> users to navigate than our current one.
>>>
>>> Currently we have a bar that consists of buttons with question numbers
>>> on them. I've only recently realised that there can be scores of
>>> questions in one section of a test, and keyboard users would have to
>>> tab through all of these before being able to answer the current
>>> question. So I thought encapsulating them into a listbox with
>>> first-letter navigation and Prev/Next arrow buttons to each side would
>>> be a good work-around. But when I began exploring the dynamics of
>>> listbox operation using a keyboard, I started to question my own
>>> wisdom.
>>>
>>> But I can't think of any other way of minimising the number of tabs
>>> required and still offering equivalent keyboard functionality.
>>>
>>> We don't design the tests, so we can't instruct authors to chop them
>>> up into smaller sections or anything sensible like that. We need to
>>> work with what we've got and make the experience as keyboard-friendly
>>> as we can.
>>>
>>> Is there a widget other than a listbox that I could use? I can't think
>>> of one off-hand.
>>>
>>> Cheers, Isabel
>>>
>>> On 02/03/2019, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
>>>> Given total freedom I'd just recommend against a listbox as a
>>>> navigation mechanism.
>>>> I think a much more effective mechanism is just a simple accordion
>>>> list of in-page links, they are fit for purpose, easy to code, and
>>>> behave consistently within the browser.
>>>> If, instead of navigating you basically load screens you can use
>>>> buttons, using aria-pressed="true" to indicate the currently active
>>>> button.
>>>> I'm not sure if a listbox breaks WCAG 3.2.2 (does the content reload
>>>> constitute a change of context as you interact with the listbox).
>>>> It depends on the specifics of how the page works.
>>>> Of course we're often not at the liberty of suggesting a drastic
>>>> re-design, we have to do the best with the current design of the page.
>>>> I think the old "go" button is not a bad idea, also have the listbox
>>>> remember the current choice, make it the default when user navigates
>>>> to the listbox.
>>>> I've implemented a completely ARIA compliant navigation megamenu
>>>> (which I was proud of but users found confusing), then a set of menu
>>>> buttons, I've ended up settling on recommending accordions, because
>>>> their much simpler to code and less confusing for users, a win win.
>>>>
>>>>
>>>> On 3/2/19, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
>>>>> Users may get confused about custom listboxes by way of how browsers
>>>>> are
>>>>> different in real native selects:
>>>>> IE fires onChange as users arrow through the options! (though it's the
>>>>> only
>>>>> one who does I believe)
>>>>> The others vary on whether blur is cancelling thing or an onChange
>>>>> thing
>>>>> (or
>>>>> whether blur is an onChange but only if the last-focussed value is
>>>>> different
>>>>> from the previous value, which I think was Firefox).
>>>>>
>>>>> If you want users to select with enter key then one way you could show
>>>>> them
>>>>> that blur is not the way is, post-blur, show what the selectedIndex
>>>>> (or
>>>>> whatever your listbox version of selectedIndex is) was. That is,
>>>>> people
>>>>> can
>>>>> go back and see what's currently selected.
>>>>>
>>>>> _m
>>>>>
>>>>> On Fri, Mar 1, 2019, at 5:01 PM, Jonathan Avila wrote:
>>>>>> I've used update on blur before with select boxes and would not
>>>>>> expect
>>>>>> tabbing out of a select box to reset my result -- I'd want tabbing
>>>>>> out
>>>>>> to keep the item I had selected with the arrow keys. For select
>>>>>> boxes
>>>>>> use of the arrow keys generally moves focus and selection together.
>>>>>> Menus are different where enter is expected to select because up/down
>>>>>> arrows only focus something but not select it. So for a menu, I
>>>>>> would
>>>>>> expect on blur to cancel the menu.
>>>>>>
>>>>>> Jonathan
>>>>>>
>>>>>>