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


--
Work hard. Have fun. Make history.