WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Listboxes that update content

for

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

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.