E-mail List Archives
Re: Listboxes that update content
From: Birkir R. Gunnarsson
Date: Mar 2, 2019 10:55AM
- Next message: Isabel Holdsworth: "Re: Listboxes that update content"
- Previous message: Patrick H. Lauke: "Re: 2.1: Testing 1.4.13 With a Screen Reader"
- Next message in Thread: Isabel Holdsworth: "Re: Listboxes that update content"
- Previous message in Thread: Mallory: "Re: Listboxes that update content"
- View all messages in this Thread
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 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
>>
>>
- Next message: Isabel Holdsworth: "Re: Listboxes that update content"
- Previous message: Patrick H. Lauke: "Re: 2.1: Testing 1.4.13 With a Screen Reader"
- Next message in Thread: Isabel Holdsworth: "Re: Listboxes that update content"
- Previous message in Thread: Mallory: "Re: Listboxes that update content"
- View all messages in this Thread