GNOME Bugzilla – Bug 640057
Orca doesn't speech selection changes on GNOME Shell
Last modified: 2011-03-09 09:09:42 UTC
GNOME Shell has several views that include item selection. Example: Alt+Tab, Ctrl+Alt+Tab, overview search etc. But with the default script those selection changes are not speeched out, because the behaviour is heavily based on the interaction with the gtktreeview on gtk. So, this behaviour should be redefined for GNOME Shell.
Created attachment 178834 [details] [review] First tentative patch This is the first tentative patch that redefines onStateChanged, in order to get a first review. Some comments: * I did it directly on the CALLY script. Someone could argue that a specific GNOME Shell script would be required, but IMHO, it is not worth right now, as GNOME Shell is the only app using that script, and the only one implementing a proper ATK_STATE_SELECTED support. We could split that in the future if more apps appear. * It speech the selection change, but not the name of the object selected. Probably the main reason is the lack of AtkSelection implementation on GNOME Shell selection code. I tried to use as workaround the name of the event.source (the object emitting the state change), but it is empty, so I would check if GNOME Shell provides a proper name for that object. Anyway, I know that the "right thing" would be implement AtkSelection for the container that holds the objects selected.
Review of attachment 178834 [details] [review]: (In reply to comment #1) > Created an attachment (id=178834) [details] [review] > First tentative patch Thanks! :-) > This is the first tentative patch that redefines onStateChanged, in order to > get a first review. > > Some comments: > > * I did it directly on the CALLY script. Someone could argue that a specific > GNOME Shell script would be required, but IMHO, it is not worth right now, as > GNOME Shell is the only app using that script, and the only one implementing a > proper ATK_STATE_SELECTED support. We could split that in the future if more > apps appear. On this I'm somewhat torn. I totally feel where you're coming from: I've had many "I have to create whole new script just for THAT?? ugh!" occasions. However, you only have to do that stuff once. And if there's a possibility (even a slim one) that one day we'll have more accessible Clutter apps needing the Cally script then.... I'm tempted to be one of those people who argues that a specific GNOME shell script should be required. But we can "fight" about that issue later. ;-) While I still need to reset up my build environment, your patch looks like it will cause Orca to say "selected" a bunch of times where we do not want it to be said. Normally (i.e. NOT in gnome-shell), when a user arrows around in a menu, or arrows around in a single-select list box (web content), or Alt+Tab's amongst open windows, Orca does not say "selected". This is by design. And the reason why we don't say it is because a screen reader should provide only that information which is needed (otherwise we're being "too chatty."). The assumption is that when you're navigating amongst these items the current item *has to be selected by definition.* In which case "selected" becomes redundant chatter. My recommendation is to compare Orca in the gnome-panel menus, metacity, nautilus, etc. and get Orca to present similar information in gnome-shell. That should both answer the question, "what should Orca present here?" and wind up giving the user a consistent experience as he/she transitions into gnome-shell.
Alex, I'm having a "senior moment." Both for my own addled brain and for the sake of documentation, where are we w.r.t. this bug? Thanks!
Current status: * With this patch orca speech out the selection changes * I plan to book a slot time in order to work on this, to have a meaningful speeched message * Probably it would also require gnome shell improvement (see bug 626660, last comments, related to "how include ATK_RELATION_LABELLED_BY/ATK_RELATION_LABEL_FOR relations on ST/javascript code")
Created attachment 182889 [details] [review] Updated patch This patch doesn't tries to speech directly the text, it just sets the locus of focus to the selected object. Tested with the current gnome-shell, we get the event speeched, so now it is gnome-shell the one that would require to have a proper name/label for the objects selected (some extra patches coming)
Review of attachment 182889 [details] [review]: Makes sense to me. And looks good modulo nits: * You added a bunch of imports, only one of which is actually used/required. Please remove the others. * We try not to exceed line lengths of 80 chars. Therefore, if you could de-nitify it before committing it, that would be awesome. Thanks!
> Tested with the current gnome-shell, we get the event speeched, so now it is > gnome-shell the one that would require to have a proper name/label for the > objects selected (some extra patches coming) About this extra patches see bug 644253
Created attachment 182895 [details] [review] Updated patch after Joanmarie review
Review of attachment 182895 [details] [review]: It wasn't necessary to attach the cleaned-up version (i.e. I figured you'd make these changes, push it to master, and then c&p a link to the commit here). Regardless.... Assuming nothing earth-shattering changes w.r.t. bug 644253, please commit this patch to master when you are ready to do so. :-)
Done http://git.gnome.org/browse/orca/commit/?id=fc948e0f6229c072abcd06b93b99bcae8b83cf89