WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Listboxes that update content

for

From: Isabel Holdsworth
Date: Mar 6, 2019 4:45AM

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