GNOME Bugzilla – Bug 650302
Combo box menu items should expose their displayed text
Last modified: 2017-08-24 00:58:47 UTC
Steps to reproduce: 1. Launch Accerciser and gtk-demo 2. Use Accerciser to compare menu items from the 'Application main window' demo and the 'Combo boxes' demo. In the case of menu items which are NOT in combo boxes, the displayed text is exposed as both the accessible name and the accessible text; in the case of menu items in combo boxes, the displayed text is exposed in neither place.* Impact: When a user has expanded a combo box and is arrowing amongst the items, screen readers such as Orca cannot present the newly-selected item in response to the selection-changed event. * That this needs to be done is not, from a cursory glance at the a11y docs, stated. I have made a note of this and will add it to the doc-rewrite to-do list.
The bug here is that gailmenuitem stupidly assumes that every menuitem must always contain a label. the menuitems in a combobox do not. they contain a cellview widget, which uses a cellrenderertext to render the text.
I think fixing this requires - removing reams of hacks from gailmenuitem.c - teaching gailmenuitem that menuitems are in fact regular containers that can have children - implementing a11y for gtkcellview
Created attachment 187937 [details] [review] a patch Here is patch that extends the current gailmenuitem hacks to also recognize cellviews inside menuitems. I didn't fully implement all of AtkText for this case. Let me know if this works sufficiently well in your testing to serve as a short-term fix.
A few things: This implements AtkText but not the name. GTK 2's behavior was to implement the name but not AtkText, although sometimes it exposed neither (for "where am I?", it exposed the text in the name for the Menus but not for their MenuItem children). I don't know if this is a concern or not (Joanie, do you have anything to add?) The patch seems like an improvement over the old behavior, anyhow. It looks as though Orca will try to get the name or the text of the selected item (as returned by atk_selection_get_selected_child) when a selection-changed event is sent. If neither returns anything, then it falls back to reading the name of the combo box. For the "where am I?" combo box, this causes a change in what Orca reads. With the patch, if I press down arrow, then Orca reads "C - D," as it does with the gtk 2 demo. Without the patch, it reads "Carson City," which is the name of the combo box. I'm not even sure what the correct behavior is, but, if reading "C - D" is not correct, then I think that it is beyond the scope of this bug. Also, there is a g_print in the patch.
Thanks for the testing !
Now that I look at it a bit more, there are problems with the way the "Where am I?" combo box is handled--it looks as though pressing up and down arrow can cycle through the sub-entries, but no events are sent unless there is a change in which direct child of the combo box has the selection--but, again, that is beyond the scope of this bug.
Review of attachment 187937 [details] [review]: committed for now
Ok, I've committed this for now, so that we have at least some support for combo boxes.
Matthias, I'm going through open Gtk+ bugs which impact Orca users to generate a to-do list. Can we close this one?
It looks like you were both happy with the fix here within its original scope, so closing, but please open a new one or reopen this if you still have related issue.