WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible, flexible select box


From: mhysnm1964@gmail.com
Date: Jan 31, 2019 3:23AM

Refer to the w3c aria 1.1 or 1.0 if you are going to do a custom list box. Many of the list boxes I have tested all break when they don't use the select.

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Isabel Holdsworth
Sent: Thursday, 31 January 2019 8:51 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Accessible, flexible select box

Thanks Birkir. No, it's just a plain old select box that we need, but one that can be styled.

I'll file a bug now. Thanks again.

On 30/01/2019, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:
> Wait, are you trying to implement a listbox (a dropdown of options) or
> a combobox (a text field that you can type in with an attached list of
> options / auto complete suggestions)?
> See the ARIA Authoring Practices patterns (section 3) for description
> and examples http://www.w3.org/TR/wai-aria-practices-1.1/
> We have implemented a custom listbox based on this example from the
> Authoring Practices
> http://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-c
> ollapsible.html If it is an auto complete you may want to code it so
> that the suggestions appear as buttons in responsive mode, I did a
> presentation of an accessible auto complete for iOS with an old friend
> of mine way back when. The presentation along with the examples can
> still be found at http://whenpush.a11yideas.com
> If iOS does not support correctly implemented ARIA listboxes, make
> sure to file a bug. They can afford to fix that.
> We can't keep telling developers not to do something that is
> technically valid because the software vendors who create assistive
> technologies aren't doing their bit. To become accessible everyone
> must chip in.
> It's that fine balance between making it usable today and making
> accessibility achievable tomorrow.
> On 1/30/19, Isabel Holdsworth < <EMAIL REMOVED> > wrote:
>> Hi Sean,
>> That's a major piece of work you guys have done! It works pretty well
>> in Chrome with JAWS too.
>> With respect, two reasons why I wouldn't advocate its use from an
>> accessibility perspective:
>> 1. The custom select identifies itself as an edit field even though
>> it's not editable. There's plenty of information available for
>> screenreader users about how to navigate and select its content, but
>> being a purist I'm still uncomfortable about using elements that
>> identify as one form field type but behave like another. Do you know
>> if a selection can be made using speech input technologies such as
>> Dragon Naturally Speaking?
>> 2. Using VoiceOver on iOS, I wasn't able to make a selection, nor
>> even in desperation enter any content into a field that identified
>> itself as an edit box. If this element were part of a form that I was
>> filling in on my phone, and the field was required, I wouldn't be
>> able to complete the form.
>> Very nice work, but IMO it needs a few tweaks to be considered accessible.
>> The search continues...
>> Cheers, Isabel
>> On 29/01/2019, Sean Curtis < <EMAIL REMOVED> > wrote:
>>> Hi Isabel,
>>> I helped improve the accessibility of the recent v2 release of
>>> react-select (https://react-select.com). Native selects are great up
>>> to a certain
>>> point:
>>> more than a couple of hundred options, especially when those options
>>> contain similar entries (like users with the same name) and the
>>> experience goes down the toilet.
>>> When digging into making this component accessible we initially went
>>> full semantics and aria. It felt "right", but we hit a wall after
>>> getting the simple stuff working. Things like aria-posinset/setsize
>>> just didn't announce consistently, activedescendant was promising
>>> but AT support was extremely patchy, announcing a loading state when
>>> fetching new options after typing had no real aria attribute
>>> (aria-loading sounded right but didn't do what it says on the box).
>>> The examples I've seen worked for selecting single values too, not
>>> for handling multi selects. We tried a mix of aria roles and live
>>> regions, but things got a bit muddled. It was difficult to predict
>>> things from a dev perspective.
>>> We ended up using live regions (we had to have 2 to reliably
>>> announce things, and this seems a common approach). The live region
>>> approach is the same route we took for react-beautiful-dnd, which is
>>> an incredibly performant yet also accessible drag-and-drop library.
>>> It's the same approach that the Downshift Select component uses
>>> also. Having one approach/implementation made it very
>>> straightforward to develop and test.
>>> This is very important for ongoing maintainability and avoiding
>>> regressions.
>>> The downside is that as a dev you now need to provide
>>> internationalized strings for the various prompts — not a huge ask
>>> but it's something you'd get for free if you were just using
>>> html+aria. It was a trade off we were happy with.
>>> I believe there are some mobile optimized styles and touch
>>> interactions for react-select out of the box. It's highly
>>> customizable as well (you can replace various components within it).
>>> Have a go and let me know how it performs. We're building upon it
>>> for our design system components at Atlassian and it's been a solid
>>> choice. It's open source so fixing it is just a PR away :)
>>> Cheers,
>>> Sean
>>>> On 30 Jan 2019, at 3:53 am, glen walker < <EMAIL REMOVED> > wrote:
>>>> Here are a few useful blogs:
>>>> Short note on the accessibility of styled form controls
>>>> <https://developer.paciellogroup.com/blog/2018/07/short-note-on-the
>>>> -accessibility-of-styled-form-controls/>
>>>> Inclusive Considerations When Restyling Form Controls
>>>> <https://24ways.org/2018/inclusive-considerations-when-restyling-fo
>>>> rm-controls/>
>>>> Accessible Styled Form Controls
>>>> <https://scottaohara.github.io/a11y_styled_form_controls/src/select
>>>> />
>>>> Styling a Select Like It's 2019
>>>> <https://www.filamentgroup.com/lab/select-css.html>
>>>> However, most of them talk about the native <select> element as a
>>>> combobox and not as a listbox.
>>>> Glen
>>>> >>>> >>>> archives at http://webaim.org/discussion/archives
>>>> >>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
> --
> Work hard. Have fun. Make history.
> > > archives at http://webaim.org/discussion/archives
> >