WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible, flexible select box

for

From: Isabel Holdsworth
Date: Jan 31, 2019 2:50AM

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