WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Listboxes that update content

for

From: Birkir R. Gunnarsson
Date: Mar 5, 2019 5:10AM

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