WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Listboxes that update content

for

From: Isabel Holdsworth
Date: Mar 4, 2019 4:34AM

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 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 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
>>>
>>>