E-mail List Archives
Re: Accessible, flexible select box
From: Sean Curtis
Date: Jan 29, 2019 1:59PM
- Next message: Jonathan Avila: "Re: Native or web?"
- Previous message: Patrick H. Lauke: "Re: Native or web?"
- Next message in Thread: Isabel Holdsworth: "Re: Accessible, flexible select box"
- Previous message in Thread: glen walker: "Re: Accessible, flexible select box"
- View all messages in this Thread
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-form-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
> > > >
- Next message: Jonathan Avila: "Re: Native or web?"
- Previous message: Patrick H. Lauke: "Re: Native or web?"
- Next message in Thread: Isabel Holdsworth: "Re: Accessible, flexible select box"
- Previous message in Thread: glen walker: "Re: Accessible, flexible select box"
- View all messages in this Thread