GNOME Bugzilla – Bug 762136
Progress of file and folder operations is no longer accessible to screen readers
Last modified: 2016-02-24 10:25:21 UTC
The new pop over window that was introduced in Nautilus 3.18 to show progress of file and folder operations is not accessible to screen readers such as Orca. The previous progress dialogs as seen in 3.16 were fully accessible. I have been advised by one of the Orca devs that the problem lies in Nautilus not emitting the necessary accessibility events.
Created attachment 321630 [details] pyatspi accessible-event listener Try the following: 1. Launch this accessible-event listener in a terminal 2. Locate a sizable file or folder in Nautilus 3. Copy and paste it 4. Click to show the popup with the progress bar Expected result: Each time the colored bar is updated, an event would be printed in the terminal. The object emitting the event would have role "progress bar." Actual result: No events are printed. To compare, try doing the same thing in Firefox or pcmanfm. In both of those cases, the listener should print out events as the progress bar updates. If you use Accerciser to examine the accessibility tree for the Nautilus popup, you'll also notice that the progress bar is not there. If your progress bar is not a custom widget, it might be worth solving this exposure problem first. (Non-custom progress bar widgets tend to emit the expected events, so solving exposure might solve events.)
Did I understand correctly, the issue is with each progress bar used inside the operations popover for every operation? FWIW Those are gtk+ stock GtkProgressBar.
Then my statement in comment 1 (solve the exposure problem first) applies: GtkProgressBar normally emits the expected events. But only accessible objects can emit accessible events. And from what I'm seeing in Accerciser, there are no accessible progress bar objects.
ok. I'm still unsure to what widget you refer to. Do you refer to each progress bar shown inside the popover itself? or the button pie chart?
do you generally get a11y events from widgets in popover otherwise, Joanie ?
(In reply to Carlos Soriano from comment #4) > ok. I'm still unsure to what widget you refer to. Do you refer to each > progress bar shown inside the popover itself? or the button pie chart? Each progress bar. Related aside: They should also be keyboard navigable. (In reply to Matthias Clasen from comment #5) > do you generally get a11y events from widgets in popover otherwise, Joanie ? When selection changes in the gtk3-demo's popover search entry, we get events. I'll see why Orca is not presenting the non-focus-grabbing popover.
Good news: I just stumbled upon a workaround and committed it (the last two commits in Orca). Turns out I can force object creation (including the progress bars under discussion) by diving down the accessibility tree. Ideally, doing a tree dive should not be needed. And it can be non-performant for containers with many children. But as long as popovers aren't enormous, it should be harmless. The keyboard navigation issue still needs to be addressed, however. And if you are interested in tackling the object exposure issue, Accerciser can still be used for that.
Created attachment 321977 [details] [review] query-editor: make search popover keyboard navigable We need to move the focus back and forth from it.
Created attachment 321978 [details] [review] toolbar: make operations popover keyboard navigable Move focus in and out from it when opening and make the info widget to be able to focus.
Created attachment 321994 [details] [review] toolbar: make operations popover keyboard navigable Move focus in and out from it when opening and make the info widget to be able to focus.
Attachment 321977 [details] pushed as f7bf1c4 - query-editor: make search popover keyboard navigable Attachment 321994 [details] pushed as 511c32c - toolbar: make operations popover keyboard navigable