Fix SingleChoiceInput accessibility issues

[foxbunny]

• Replace SUI's Dropdown compoennt with a custom Combobox component
• Implement a custom element used by Combobox
• Add useNativeEvent hook
• Tweak regform styles to handle the new controls

[micsucmed]

Hi @foxbunny, could you please explain in more detail what accessibility issues you're trying to solve here? I think you meant usability. There is still an issue when the user types in an entry that is not part of the drop-down options; there is no feedback that this entry is not valid and will not be sent (Given that the field is not required). And even if the field is required, the feedback gotten is "This field is required", which can be confusing since the user might think the field input has been provided, but in reality the input is not valid.

[foxbunny]

please explain in more detail what accessibility issues you're trying to solve here

The primary accessibility issues that are being solved is incompatibility of the SUI combobox with screen readers. In particular, not announcing the options, not being clear about what effect the typing has, etc.

There is still an issue when the user types in an entry that is not part of the drop-down options

I've already pointed this out to @ThiefMaster. It's a validation issue, not really an accessibility issue.

[tomasr8]

Thanks for the PR!

I've already pointed this out to @ThiefMaster. It's a validation issue, not really an accessibility issue.

Can we do something about it in this PR?

Here's just some small styling issues I noticed:

When expanded I'd disable the bottom border radius on the input field:

I'd align the options with the text input as it was before (i.e. increase left padding for the options)

The list needs a higher z-index:

From a usability point of view, I noticed that if I have two options, one uppercase and one lowercase e.g. A and a, when I type lowercase a, the A option is auto selected. That's not what I'd expect, especially since it changes the character I typed (from a to A)

[foxbunny]

Can we do something about it in this PR?

My understanding was that it wasn't something we can do, but I can check the code, sure.

Here's just some small styling issues I noticed:

Gotcha. Thanks.

From a usability point of view, I noticed that if I have two options, one uppercase and one lowercase e.g. A and a

Hmmm. I'm not sure we should support this case at all. See, for screenreaders, there's absolutely no difference between capital A and lowercase a. So even if I make the combobox do case-sensitive matching in case of conflicts, it won't help screenreader users one bit.

[tomasr8]

Hmmm. I'm not sure we should support this case at all. See, for screenreaders, there's absolutely no difference between capital A and lowercase a. So even if I make the combobox do case-sensitive matching in case of conflicts, it won't help screenreader users one bit.

I can imagine regular users not being happy with the combobox changing their input.. If it doesn't hurt screenreader users I'd prefer case-sensitive matching

[foxbunny]

I can imagine regular users not being happy with the combobox changing their input.. If it doesn't hurt screenreader users I'd prefer case-sensitive matching

Do you really intend to have options that are identical except for the case? If you ask me, I'd forbid that during form creation.

[foxbunny]

Anyway, back to the discussion on case-matching. Suppose we have the following items in the list:

• ACME
• Acme
• acme
• aCme
• aCMe

The most trivial thing we can do is match at the start of the string case-sensitively. For example, if we type "A", it matches "ACME". If we type "Ac", it matches "Acme" and not "ACME".

This has some edge cases. For example, if we type "acM" it will match "ACME" and not "acme" or "aCme" even though the first character is lower-case.

How elaborate do you want this algorithm to be? For example, we could count the number of characters that match by position and case. Or we could count the longest perfectly matching consecutive characters. Etc.

[tomasr8]

How elaborate do you want this algorithm to be?

A more radical idea, but what if we just don't autocomplete? As in, we keep the behaviour of the current dropdown?
My issue is purely with the fact that the input is actively changing what I'm typing, but maybe others have a different opinion? @ThiefMaster @micsucmed

On an unrelated note:

• In the current dropdown one can search for any part of the text e.g. if you type cme you'll see acme as an option. I would prefer not to lose this functionality as it makes the search more useful
• A quick way to unselect the currently-selected option would be nice. The SUI dropdown has this x icon on the right side, maybe we could add it as well?

[foxbunny]

In the current dropdown one can search for any part of the text e.g. if you type cme you'll see acme as an option. I would prefer not to lose this functionality as it makes the search more useful

I deliberately avoided using that approach because it causes usability issues such as matching something that isn't obviously what the user started off to type. (For instance in the country selector you start to type "Ser" it will give you "Montserrat" as the first option.) But anyway, I leave that up to you.

A quick way to unselect the currently-selected option would be nice. The SUI dropdown has this x icon on the right side, maybe we could add it as well?

Sure, we can add that.

[foxbunny]

Updated the PR.

Fix styling issues, and implemented two strategies for handling typing based on the aria-autocomplete attribute, so now you can do both autocomplete and search (documented). Also added the clear button.

[foxbunny]

Rebased on master, and also fixed the validation logic so it correctly traps invalid choices.

[foxbunny]

@tomasr8 Reminder, just in case.

[tomasr8]

I noticed some differences from the old dropdown. Some of these might be nice to keep for the new one as well:

• no results message:

• I'd keep the same x icon:

vs

• When you have extra slots the dropdown to select the amount is much wider now (and the combobox changes width):

vs

• The hover bg color is the same as the one for the price now so it blends together:

vs

I'd also increase the height of the listbox a bit, currently it feels a bit too small

[foxbunny]

When you have extra slots the dropdown to select the amount is much wider now (and the combobox changes width)

Do we even need the amount drop-down to be a combobox? I can replace it with a plain select list.

[foxbunny]

no results message:

It would take a lot of additional code to get this feature in. I think there isn't such a dramatic difference between saying there are no matches and showing no matches from the UX standpoint, and therefore the additional work, maintenance burden, and complexity aren't justified. Of course, if you insist that this feature is crucial, I can still add it.

[tomasr8]

no results message:

It would take a lot of additional code to get this feature in. I think there isn't such a dramatic difference between saying there are no matches and showing no matches from the UX standpoint, and therefore the additional work, maintenance burden, and complexity aren't justified. Of course, if you insist that this feature is crucial, I can still add it.

Ok if it'd require a lot of extra work we can leave it out

Do we even need the amount drop-down to be a combobox? I can replace it with a plain select list.

I think so :)

[foxbunny]

I think so :)

Ok. I've pushed a fix for the combobox widths. Right now, these controls use different implementations (number of extra slots uses SUI dropdown). My plan is to replace the other ones once this PR is merged so we don't do too much in a single PR. Meanwhile you can adapt this to the time picker, for instance. Let me know if that works for you.

[tomasr8]

Ok. I've pushed a fix for the combobox widths. Right now, these controls use different implementations (number of extra slots uses SUI dropdown). My plan is to replace the other ones once this PR is merged so we don't do too much in a single PR. Meanwhile you can adapt this to the time picker, for instance. Let me know if that works for you.

As long as the look is consistent across the different dropdowns it should be fine