As of v0.21.2, we're adding role=listbox on several elements which don't have sub-items role=option provided.
This is required for role=listbox.
Widgets affected in the demo:
Basically every role=listbox carrying element where there are no subitems providing them when they are disabled, empty or gets dynamically filled after input.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| ComboBoxInputWidget: Remove ARIA roles when menu is empty | oojs/ui | master | +6 -1 |
Change 352303 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] ComboBoxInputWidget: Remove ARIA roles when menu is empty
@matmarex You might miss something here. ARIA clearly states “Required Owned Elements: option“.
Try to think about it from a screen readers perspective. We're exposing listbox to assistive technology. Screen reader tells “here comes the list(box) labelled …“. But then you've got no choices as there are no options. It doesn't make sense to yell listbox, when there are no options.
If the spec does not allow a listbox to be empty, that's a mistake in the spec. It is obvious to me that a listbox can have zero options. Even HTML allows a <select></select>. Here's an example which features empty listboxes: https://www.w3.org/TR/wai-aria-practices/examples/listbox/listbox.html
Removing the role=listbox attribute will also mess up relations like aria-owns that point to the listbox. It seems like a major pain to implement. I find it hard to believe that the writers of the ARIA spec (which otherwise seems very sensible) would require that.
For ComboBoxInputWidget specifically, maybe we can pretend it's a simple text field when its menu is empty (although I don't see the point). But this wouldn't make sense e.g. for DropdownWidget.
Other possible cleaner to implement ideas would be to
Later seems the simplest way out, but has the potential pitfall that such a hidden for screen readers element might break the user flow
Ok, ARIA 1.0 was requiring listbox, ARIA 1.1 combobox is only requiring textbox or searchbox:
Authors MUST ensure an element with role combobox contains or owns a text input element with role textbox or searchbox and that the text input has aria-multiline set to false. If the combobox provides autocompletion behavior for the text input as described in aria-autocomplete, authors MUST set aria-autocomplete on the textbox element to the value that corresponds to the provided behavior.
Even with that a misconception remains:
combobox is IMHO just the wrong role for our dropdowns and with it aria-autocomplete="list". It doesn't make any sense as long as we don't provide an text input.
Change 352303 abandoned by VolkerE:
ComboBoxInputWidget: Remove ARIA roles when menu is empty
Reason:
Seems unnecessary with close look to newer ARIA definitions.
As ARIA 1.1's combobox has lightened up the path, this original task description is not longer accurate and gives way to @matmarex comment about confusing spec. Follow-up at T212186: DropdownWidget misses required ARIA child roles and attributes