WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible, flexible select box

for

From: Birkir R. Gunnarsson
Date: Jan 30, 2019 7:43AM

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


--
Work hard. Have fun. Make history.