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
>>>
>>> -----Original Message-----
>>> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
>>> glen walker
>>> Sent: Friday, March 1, 2019 10:21 AM
>>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>>> Subject: Re: [WebAIM] Listboxes that update content
>>>
>>> CAUTION: This email originated from outside of the organization. Do not
>>> click links or open attachments unless you recognize the sender and
>>> know the content is safe.
>>>
>>>
>>> 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.
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>> >>> >>> >>> >>>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >