WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Listboxes that update content

for

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

On 06/03/2019, Isabel Holdsworth < <EMAIL REMOVED> > wrote:
> 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
>>>>>>
>>>>>>