WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible, flexible select box

for

From: Isabel Holdsworth
Date: Jan 31, 2019 6:32AM

All done and dusted. JAWS and NVDA are aware of how many items are in
the list, which item is selected, etc. It works very well with
everything except VoiceOver on iOS. I don't like custom controls, but
this one is as good as it gets.

Thanks everyone for your thoughts, , links to articles etc. This issue
has been bubbling on for months and I'm glad to be done with it :-)

On 31/01/2019, <EMAIL REMOVED> < <EMAIL REMOVED> > wrote:
> 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
>> >>
> > > http://webaim.org/discussion/archives
> >
> > > > >