Page MenuHomePhabricator

DropdownWidget misses required ARIA child roles and attributes
Closed, ResolvedPublic

Description

As of v0.29.6 DropdownWidget misses required ARIA child roles and attributes as outlined in the spec.

Originally coming from T164632#4575507

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.

Event Timeline

Change 480432 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] DropDownWidget: Turn handle into button and add ARIA attribute

https://gerrit.wikimedia.org/r/480432

Volker_E moved this task from Backlog to Reviewing on the OOUI board.Dec 18 2018, 10:41 PM

Change 480432 merged by jenkins-bot:
[oojs/ui@master] DropDownWidget: Turn handle into button and add ARIA attribute

https://gerrit.wikimedia.org/r/480432

I am not a fan of this solution. I think the previous version worked better (even if it had violated the ARIA spec, which it didn't, it was compliant with the ARIA 1.0 pattern rather than the ARIA 1.1 pattern, they are both still allowed).

At least on Windows, previously our dropdowns behaved identically to native dropdowns (tested using Windows Narrator and Firefox/Chrome/Edge): they were read as "editable combobox", which is questionable (the text is not editable, you can only choose options) but mostly correct (and consistent to native dropdowns in the OS, which are also read as "editable combobox" or in some cases just "combobox"). Now they are reported as buttons, which seems just wrong.

…Except in Chrome; it reads them as "expanded menu item; expanded" (even when the dropdown is collapsed), which is just entirely wrong and insane. Chrome's accessibility inspector reports this element as a combobox still (apparently anything with button role and aria-haspopup is reported as combobox), but it does not read them as combobox.

My main goal when developing all OOUI widgets has always been to make them no worse than the native widgets, and I think we regressed here.

Side note: spacebar no longer expands the dropdown on Firefox (probably something weird with event handling due to using a <button>).

As far as I can tell, the only goal of this change was to quieten accessibility testing tools. If that is the case and some dumb tool is complaining about a missing textbox inside the combobox, then a) I would like us to stop using that tool since it is clearly bad b) we can just stick a freaking textbox in there that does nothing if that makes you happy.

As far as I can tell, the only goal of this change was to quieten accessibility testing tools. If that is the case and some dumb tool is complaining about a missing textbox inside the combobox, then a) I would like us to stop using that tool since it is clearly bad b) we can just stick a freaking textbox in there that does nothing if that makes you happy.

@matmarex I fully agree with a) and we should stop using Windows Narrator. It has never been a fully functional web screen reader as far as I know. Screen reader users on Windows use JAWS or NVDA by far majority.
Axe, which also builds the core of Lighthouse accessibility testing audits, on the other hand has been praised in the a11y community for its accuracy – and it's the only a11y testing tool that is fully accessible itself.
So to summarize, no, the goal is not to “quieten accessibility testing tools”, that's the same comparison as “fixing the function by quieten eslint”?! The goal has been to eliminate stated errors, which are based on the ARIA specs, from our widgets, which in turn are confusing screen reader users. The spec is the source of truth for browser vendors to build their accessibility tree which they expose to screen readers and not following it without excellent reason makes no sense to me.

To your point about “previous version worked better”:
A combobox is a combobox, but with dropdowns there was no combo as there was no input, only a button-like element. I don't understand how we should hold on to make a dropdown widget no worse than a native select <select size="0">, when we promise screen reader users something that is not there.
Safari/Firefox/Chrome w VoiceOver all expose latter with reading “popup button” exactly how it's accomplished now with the button and listbox approach.
As ARIA best practice is following the same path, it's actually closer to what you've had in mind with “no worse than native widgets”. A dropdown is no more than a button with a menu.

Once more, a combobox in comparison:
https://www.levelaccess.com/differences-aria-1-0-1-1-changes-rolecombobox/

The purpose of role=”combobox” is to enable auto-suggest functionality within editable or readonly edit fields where a list of options can be selected based on conditional rendering.

And comboboxes from ARIA best practices for version 1 and 1.1.: https://w3c.github.io/aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html
Not a single dropdown equivalent there.

I will download JAWS and NVDA and test with them as well.

I tested Axe. It may be an excellent tool, but its results are definitely incorrect here. Our widgets use the role=combobox as described in the ARIA 1.0 spec, and Axe seems to only implement the 1.1 spec.

To your point about “previous version worked better”:
A combobox is a combobox, but with dropdowns there was no combo as there was no input, only a button-like element. I don't understand how we should hold on to make a dropdown widget no worse than a native select <select size="0">, when we promise screen reader users something that is not there.

I think this is just a matter of definition, but comboboxes can definitely be non-editable (a.k.a. readonly). You'd probably call a non-editable combobox a "dropdown" (and that's what we call them in OOUI), but I think the ARIA definition of a combobox covers both editable and non-editable comboboxes.

I experimented a bit and it seems that we could also put aria-readonly="true" on the element to better express this to screen readers.

And comboboxes from ARIA best practices for version 1 and 1.1.: https://w3c.github.io/aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html
Not a single dropdown equivalent there.

Well, that seems like a shortcoming of that document ;) Here are some examples of using ARIA role=combobox for non-editable comboboxes:

A dropdown is no more than a button with a menu.

I can't agree with this. In addition to being a button with a menu, a dropdown (or a combobox) must at the very least also have support for up/down arrow keys to select the previous/next item, and for type-to-search.

I will download JAWS and NVDA and test with them as well.
I tested Axe. It may be an excellent tool, but its results are definitely incorrect here. Our widgets use the role=combobox as described in the ARIA 1.0 spec, and Axe seems to only implement the 1.1 spec.

[…]

I think this is just a matter of definition

ARIA 1.0 role=combobox

A presentation of a select; usually similar to a textbox where users can type ahead to select an option, or type to enter arbitrary text as a new item in the list. See related listbox.
combobox is the combined presentation of a single line textfield with a listbox popup.
Required Owned Elements:

listbox
textbox

ARIA 1.1 role=combobox

A composite widget containing a single-line textbox and another element, such as a listbox or grid, that can dynamically pop up to help the user set the value of the textbox.
Authors MUST ensure an element with role combobox contains or owns a text input element with role textbox or searchbox
Required Owned Elements:
textbox and, when expanded, one of:

listbox
tree
grid
dialog

I don't know what we're discussing here: Our DropdownWidget before has had role=combobox assigned, but had no required textbox. The example of whatsock.com given with no input textbox is just faulty.

In addition to being a button with a menu, a dropdown (or a combobox) must at the very least also have support for up/down arrow keys to select the previous/next item, and for type-to-search.

That's an argument I can follow, if there's functionality missing we need to work on it.

Ok, although I think dropdowns are working by and large with the patch per spec and in my testing, I'm considering another, sligthly different approach to satisfy equivalence with Narrator's native dropdown exposure and the spec's related concepts definition.

Change 481052 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] DropdownWidget: Alternative ARIA roles and attributes approach

https://gerrit.wikimedia.org/r/481052

Change 481239 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] Update OOUI to v0.30.0

https://gerrit.wikimedia.org/r/481239

Change 481239 merged by jenkins-bot:
[mediawiki/core@master] Update OOUI to v0.30.0

https://gerrit.wikimedia.org/r/481239

Volker_E added a comment.EditedJan 14 2019, 10:40 PM

To be more clear, ARIA 1.1 and WD 1.2 are defining role=combobox related HTML concept to be select.
While the button and haspopup should work for majority of screen readers to navigate dropdowns sufficiently, a native OS select field would be read out as combobox as identified by @matmarex use of Narrator in T212186#4834710 when the screen reader software actually follows the spec.
Therefore a combobox with added attributes and a readonly textbox role that exposes the default or currently selected value.

Volker_E raised the priority of this task from Medium to High.Jan 14 2019, 10:44 PM

Just coming from A11yCampBay, this is a nice resource, basically repeating combobox being the more appropriate role https://gerardkcohen.github.io/periodic-table-of-semantics.html

Change 481052 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[oojs/ui@master] DropdownWidget: Alternative ARIA roles and attributes approach

https://gerrit.wikimedia.org/r/481052

Change 481052 merged by jenkins-bot:
[oojs/ui@master] DropdownWidget: Alternative ARIA roles and attributes approach

https://gerrit.wikimedia.org/r/481052

Volker_E moved this task from Reviewing to OOUI-0.32.0 on the OOUI board.May 20 2019, 11:25 AM
Volker_E edited projects, added OOUI (OOUI-0.32.0); removed OOUI.

Change 513020 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/core@master] Update OOUI to v0.32.0

https://gerrit.wikimedia.org/r/513020

Change 513020 merged by jenkins-bot:
[mediawiki/core@master] Update OOUI to v0.32.0

https://gerrit.wikimedia.org/r/513020

Volker_E closed this task as Resolved.May 29 2019, 10:56 PM

This is resolved. \o/

Will reach out to affected users and see if they have any further comments or requests. If so, will filed as separate tasks.