E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 10 (In chronological order)

From: Isabel Holdsworth
Date: Tue, Jan 29 2019 4:42AM
Subject: Accessible, flexible select box
No previous message | Next message →

Hi all,

An app that I'm working on needs a select box, and my colleagues are
leaning towards a custom select using ARIA listbox and option roles.

IMHO custom selects don't offer a good user experience on iOS.

But native selects are difficult to style, and especially to apply our
huge range of colour contrast options. We run Chrome in a secure
client that apparently doesn't respect the OS's high contrast mode, so
we fake it. But native selects don't respect our simulated high
contrast UI.

Using native and custom selects together and hiding the custom one
from screenreaders isn't an option, as it could then be hidden from
speech input technologies as well.

I'd really appreciate any thoughts or ideas you might have.

Cheers, Isabel

From: JP Jamous
Date: Tue, Jan 29 2019 7:22AM
Subject: Re: Accessible, flexible select box
← Previous message | Next message →

We struggle with that as well. I know it does not answer your question, but
we decided to keep using <select>. That way, the user is in control of his
or her environment.

Creating a select box will require lots of work. Also, no one knows how it
will render with each Assistive Technology. Lastly, it breaks the first
principle of ARIA. If it can be done using HTML, then avoid using ARIA.

I would vote for your choice and do not fully support theirs. Unless there
is a strong business requirement that forces the use of a custom select box,
just don't waste the time and money on it.



--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------

From: glen walker
Date: Tue, Jan 29 2019 9:53AM
Subject: Re: Accessible, flexible select box
← Previous message | Next message →

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

From: Sean Curtis
Date: Tue, Jan 29 2019 1:59PM
Subject: Re: Accessible, flexible select box
← Previous message | Next message →

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

From: Isabel Holdsworth
Date: Wed, Jan 30 2019 4:41AM
Subject: Re: Accessible, flexible select box
← Previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Wed, Jan 30 2019 7:43AM
Subject: Re: Accessible, flexible select box
← Previous message | Next message →

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

From: Isabel Holdsworth
Date: Thu, Jan 31 2019 2:50AM
Subject: Re: Accessible, flexible select box
← Previous message | Next message →

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

From: Isabel Holdsworth
Date: Thu, Jan 31 2019 2:53AM
Subject: Re: Accessible, flexible select box
← Previous message | Next message →

Thanks Glen, we've looked at most or all of these blogs already, but
apparently the native <select>, even with custom styling, still isn't
flexible enough. Very frustrating!

On 29/01/2019, glen walker < = EMAIL ADDRESS 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
> > > > >

From: mhysnm1964
Date: Thu, Jan 31 2019 3:23AM
Subject: Re: Accessible, flexible select box
← Previous message | Next message →

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.

From: Isabel Holdsworth
Date: Thu, Jan 31 2019 6:32AM
Subject: Re: Accessible, flexible select box
← Previous message | No next message

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 ADDRESS REMOVED = < = EMAIL ADDRESS 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.
>
>