1877877 - Replace custom selects with native widgets

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Bug Creation/Editing, defect)

Description

[James Teh [:Jamie]]

Some time in the last month, the dropdowns for product, component, platform, OS, severity, priority, etc. fields on the enter_bug and show_bug forms were changed to a custom widget rather than an HTML <select>. This has caused significant regressions for me as a screen reader user. Ordered from most problematic to least problematic:

1. The fields are no longer labelled. Note that while some of the <bz-select> elements have labels, this is not sufficient because the thing that actually gets focus for a11y is the role="combobox" inside the shadow DOM. That is what needs to be labelled.
2. When you press the arrow keys to make a choice, a dialog opens. This dialog contains a list box, but none of the options in that list box ever get focus. The result is that I get no feedback whatsoever when I'm trying to make a selection.
3. For the filterable dropdowns (e.g. Component), the list box does get focus if I tab from the filter text box. However, the options still don't get focus.
4. The <bz-select> element gets the editable accessibility state for some reason. This means that these get included when quick navigating by text box using my screen reader, making it much less efficient to get to text boxes.
   I actually don't understand why this is happening. The editable state is only exposed if Firefox allows editing on this node, which is normally only the case if contentEditable is set. But contentEditable isn't set on this node as far as I can tell.
5. The filter text box in the dialog has role="search", which is incorrect. role="search" is for a landmark for a group of controls associated with search. For a text box used for search like this one, it should have role="searchbox".

Comment 1

[:glob ✱]

dkl: I think we're at the point where the gains from the custom selects are not outweighed by their benefits. Please remove them.

Comment 2

[Kohei Yoshino [:kohei]]

I haven’t gone through the list one by one, but the options not getting focus is intentional; the combobox instead has aria-activedescendant to follow the APG combobox pattern. The filter box having the search role is a simple mistake; I know it’s a landmark role.

Comment 3

[:glob ✱]

(In reply to Kohei Yoshino [:kohei] from comment #2)

I haven’t gone through the list one by one, but the options not getting focus is intentional; the combobox instead has aria-activedescendant to follow the APG combobox pattern. The filter box having the search role is a simple mistake; I know it’s a landmark role.

Don't spend any more time on addressing issues with the custom select, unless it's to remove them.

Comment 4

[Kohei Yoshino [:kohei]]

(In reply to :glob ✱ from comment #3)

Don't spend any more time on addressing issues with the custom select, unless it's to remove them.

I got it.

Comment 5

[James Teh [:Jamie]]

I realise these are being removed, but for reference:

(In reply to Kohei Yoshino [:kohei] from comment #2)

the options not getting focus is intentional; the combobox instead has aria-activedescendant

1. When I said focus, I meant a11y focus; sorry for not being clearer. That includes aria-activedescendant.
2. I'm not sure why, but for whatever reason, the aria-activedescendant implementation here just isn't working. I'm just guessing, but it might be because of shadow DOM boundaries. Ids are scoped to the nearest shadow root or document ancestor, so if you're trying to refer across that boundary, it isn't going to work.

Comment 6

[David Lawrence [:dkl]]

Bug 1870891 which introduced the custom select changes and it's dependent commits has been reverted as requested. Production has been updated as well.