GNOME Bugzilla – Bug 668406
[blocked] Cannot navigate past certain WebKitGtk widgets once activated
Last modified: 2015-09-08 18:34:22 UTC
To reproduce, visit a web page, using Epiphany Browser, having at least one combo box. Put focus onto the combo, either using the 'c' key or navigating with the tab key. Attempt to select an item, using the space key-- a menu appears. Using the up and down arrow keys, highlight an option. Pressing the enter key is supposed to sselect the item, and allow navigation out of the combo. The menu remains, and navigation is not possible. If you click your mouse or track-pad, focus will move away from the combo. If you return to the combo, you will find that the default value is selected.
I think what we might want/have to do here is provide an Orca "get me out of this field" navigation command, because: 1. Orca doesn't do caret navigation in WebKitGtk/Epiphany. That's one of the reasons we are able to be so much more performant, present text selection, etc., etc. 2. Without using Orca, and with using any toolkit (not just WebKitGtk), the expected behavior of an expanded combo box when the user presses Enter is to collapse the combo box. The user who wishes to move focus out of the combo box is then expected to move to the next form field via the mouse or keyboard (e.g. by pressing Tab). But, of course, that user is probably sighted and doesn't require caret navigation to read what text is there. So.... A couple of possibilities spring to mind: 1. An Orca command which moves to the next, previous caret-navigable location 2. Orca starts paying attention the press of the Escape key for WebKitGtk content. Then, when Escape is pressed, and if the user is in a focusable widget, we move the caret outside of the focused widget so navigation could resume. So in the particular case of combo boxes, you'd press Enter to collapse the combo box and then Escape to move out of the combo box. I am open to other ideas. Also, I am CCing the WebKitGtk accessibility guy just in case he feels that this should be handled on their end instead of ours.
Update: Because I am currently at Igalia HQ, I was able to talk to Mario in person and show him the problem. He suggested that this is probably something they could handle on the WebKitGtk side which would be beyond awesome in terms of being more reliable and more performant for Orca users. Therefore I have filed the following: * https://bugs.webkit.org/show_bug.cgi?id=76796 (Combo boxes) * https://bugs.webkit.org/show_bug.cgi?id=76797 (Entries)
This will get fixed as part of creating an Orca-controlled caret for WebKitGtk content. Thus marking as a duplicate of bug 754740. *** This bug has been marked as a duplicate of bug 754740 ***