Some of MediaWiki's dropdown boxes (e.g. the list of block reasons, the protection page) have always been a bit interesting with screen readers since long before OOUI was a thing, but ever since the latest MediaWiki update on the English Wikipedia and the upgrade to OOUI v0.44.2, *all* dropdown boxes on MediaWiki have become borderline unusable with my screen reader JAWS, even Special:Log. Now nothing gets read when arrowing up and down through the dropdown boxes (e.g. the first one at Special:log), and Chrome becomes unresponsive while trying to expand them while JAWS is running. These dropdown boxes are unreadable with JAWS in the latest stable versions of Chrome (my primary browser), Firefox, and Edge. They still work fine on Fandom (the first non-Mediawiki wiki I thought to try them on). I personally know the interface well enough to be able to work around the dropdown boxes in a pinch, but I'd very much appreciate it if this bug was fixed.
Description
Details
Related Objects
Event Timeline
@Graham87: Thanks for reporting this. For future reference, please use the bug report form (linked from the top of the task creation page) to create a bug report, and fill in the sections in the template. Thanks.
May be caused by my changes from T309916: Page up/down, home and end don't work for navigating select lists in OOUI, which were intended to improve keyboard accessibility.
Notably, we now allow using up/down arrows to change the selection in the dropdown without opening it – previously, the first up/down arrow press would only open the dropdown, and subsequent presses would change the selection. But as an unforeseen consequence, because the dropdown isn't open, the options are not available to accessibility software.
I'm not sure what you mean by "expand", do you mean pressing Space or Enter to open the dropdown to show all options? I don't know how any of the recent changes could cause the browser to become unresponsive when doing that. Maybe it's somehow related and will fix itself when we fix the other problem.
I will work on a patch. I'll add a link to the demo here once I have it working, in a day or two – I would appreciate if you could test it then and see if the issues are fixed. Sorry about that…
No worries, these things happen. By "expand the combo box", I mean pressing enter on an option to select it, which causes the combo box state as reported by JAWS to change from collapsed to expanded. JAWS is notorious for hooking deep into Windows, so I can see it causing crashes like that (but they're still quite unusual for Chrome). I'll be happy to test things out when they're ready.
Change 822199 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[oojs/ui@master] DropdownWidget: Add screen reader support while collapsed
Test wiki created on Patch demo by Matma Rex using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/7bff0f0446/w
Also created an OOUI Demos page:
https://patchdemo.wmflabs.org/wikis/7bff0f0446/w/build/ooui/demos
@Graham87 Sorry for the delay, I've been busy recently.
You can try a demo of the new version. I hope it works well for you. For reference, you can also try a demo of the current version, and a demo of the previous version before this bug was introduced.
Feel free to browse and edit those wikis if that helps, they are temporary test wikis that will be deleted once we're done testing.
Thanks very much! They do read now ... but JAWS reads the combo box items out twice (NVDA reads them out once). Also, in JAWS (but not NVDA), I was still able to get Chrome to become unresponsive by pressing enter on the import log item (as an example) in the new demo. It seems for some reason that presseng enter in JAWS in both the current and new versions (but not the old one) tries to set the state of the dropdown box to expanded, but it didn't do so in the old version.
Change 822487 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[oojs/ui@master] DropdownWidget: Do not set label pointing to itself
@Graham87 Here are two attempts to improve the behavior of labels:
I'd also appreciate if you could try out the same on Special:Contributions, and check how the namespaces dropdown there behaves – it's slightly different from Special:Log, since it has an additional label:
- demo of the new version 2A (Special:Contributions)
- demo of the new version 2B (Special:Contributions)
Please compare 2A and 2B, and note if any of the labels are being read twice, or not being read at all (the label of the dropdown itself containing the selected option, the labels of dropdown options as you navigate, and the additional label on the namespaces dropdown).
I found two different bugs that may cause the labels to be read twice. 2A includes a fix for one of them, while 2B includes fixes for both. I want to try them separately, because the code causing the second potential bug is something that has been recommended to us by an accessibility consultant in the past as a fix for the selected option not being read out (T255316). I'm not sure if we've fixed that otherwise somehow, or if it would still be an issue.
Thank you for your help :)
In both the demos, the label is read (i.e. for Special:Log) and the options are read once, as intended. I like demo 2B better because it's more stable when I fiddle around with it, doing things I probably wouldn't do in a real-life situation (e.g. going quickly in and out of forms/focus mode, tabbing in and out of the dropdown box, etc.) Even the demo of the old version couldn't really handle this kind of thing. I'm not sure what you mean by the additional label in the namespace selector.
Thanks, I'm glad that works well.
I've been also testing with different browsers and found that 2B causes the label to not be read when using Windows Narrator with Firefox. I don't think that's a common combination, but if one thing is broken this way then others may be too, and it's a pretty bad way to fail. I guess we need to go with 2A then.
Other than the difference in labels, both demos are the same, so they should feel pretty similar.
I'm not sure what you mean by the additional label in the namespace selector.
On Special:Log, the log type dropdown doesn't have a separate label, it just displays the value of the selected option (starting with "All public logs").
On Special:Contributions, the namespace dropdown has the label "Namespace:", in addition to displaying the value of the selected option (starting with "all").
On both pages there is also a label for the whole form, and the heading of the page, so you might be hearing one of those in addition to the dropdown labels.
Change 822487 abandoned by Bartosz Dziewoński:
[oojs/ui@master] DropdownWidget: Do not set label pointing to itself
Reason:
We still need to set the label this way after all, otherwise at least Windows Narrator with Firefox doesn't read it out.
Change 822199 merged by jenkins-bot:
[oojs/ui@master] DropdownWidget: Add screen reader support while collapsed
Change 824279 had a related patch set uploaded (by Jforrester; author: Jforrester):
[mediawiki/core@master] Update OOUI to v0.44.3
Test wiki on Patch demo by Matma Rex using patch(es) linked to this task was deleted: