GNOME Bugzilla – Bug 677503
"Blocking program" buttons lack accessible names and labels
Last modified: 2021-07-05 14:28:24 UTC
Created attachment 215677 [details] event listener Steps to reproduce: 1. Launch the attached event listener 2. Launch emacs and type some text 3. With emacs focused select logout from the user menu 4. In the resulting dialog, tab amongst the three focusable objects. Expected results: All three focusable objects would have an accessible name or an accessible label (which the listener would print out). Actual results: The cancel and log out buttons have accessible names. But the button associated with the blocking program emacs does not. There is also no relationship pointing from that button to the accessible emacs label. Impact: When Orca users Tab to the buttons for blocking programs, they don't know what they are on.
Created attachment 215678 [details] Dump of the accessible hierarchy What I really wanted to provide was a screen shot of the dialog in question. But it seems that the act of capturing the screen shot causes the "blocking program" dialog to not appear as expected. I also have yet to figure out the pattern of when I will get that dialog versus the 60 seconds to log out dialog. So the attached is hopefully sufficient to show what dialog I mean. ;) It should also show the lack of name and relation. :)
(In reply to comment #1) > What I really wanted to provide was a screen shot of the dialog in question. > But it seems that the act of capturing the screen shot causes the "blocking > program" dialog to not appear as expected. Oh, are you sure? The opposite (read: taking the screenshot not working while the dialog is up) would be expected. A workaround for that case is to launch gnome-screenshot with a timeout (-d 5 for instance). > I also have yet to figure out the > pattern of when I will get that dialog versus the 60 seconds to log out dialog. It is something applications request explicitly, so it only works with some apps. Having an unsaved document in gedit should work. > So the attached is hopefully sufficient to show what dialog I mean. ;) Yupp, no worries :)
(In reply to comment #2) > (In reply to comment #1) > > What I really wanted to provide was a screen shot of the dialog in question. > > But it seems that the act of capturing the screen shot causes the "blocking > > program" dialog to not appear as expected. > > Oh, are you sure? The opposite (read: taking the screenshot not working while > the dialog is up) would be expected. A workaround for that case is to launch > gnome-screenshot with a timeout (-d 5 for instance). That's what I did. Over and over again. The dialog wouldn't show up if I were taking a screen shot. I kid thee not. I tried restarting gnome-shell, I tried logging out, I tried changing what had focus. It was insane. As an aside, at times I can make no dialog whatsoever appear in response to selecting log out from the user menu. But it's never the same steps twice and I've not yet found the trigger. But when I find it, I'll file it. > It is something applications request explicitly, so it only works with some > apps. Having an unsaved document in gedit should work. Yup. But that also causes a gedit dialog to appear. I went with Emacs because I was aiming for the simplest case.
Created attachment 215692 [details] Not the right dialog - 1 (screenshot) Here's a screen shot in which I didn't get the expected dialog or the 60 second one.
Created attachment 215693 [details] Not the right dialog - 2 (screenshot) Here's a screen shot which kinda sorta looks like the right one (it mentions applications to be quit). But where's the Emacs button I want labeled by Piñeiro? <shrugs>
Created attachment 215694 [details] No dialog at all Sorry for the size on this one (dual-head system, large rotated screens, scaled down to make bugzilla happy). This is one in which I gave it 10 full seconds so that I could give Emacs focus again (in case that mattered; it didn't). Then I chose logout and waited. And waited. No dialog at all, anywhere on that screen. And apologies for the noise. But I wanted to prove that I am not making this up. ;)
(In reply to comment #0) > 3. With emacs focused select logout from the user menu > 4. In the resulting dialog, tab amongst the three focusable objects. I was not able to reproduce this with emacs, but .. (In reply to comment #2) > It is something applications request explicitly, so it only works with some > apps. Having an unsaved document in gedit should work. I was able to reproduce it with gedit. FWIW, testing it, when the dialog appears, Orca exposes all the text (including "gedit not responding") I will take a look to this bug.
Created attachment 215725 [details] [review] Sets the label actor for those ListItem on that dialog This patch solves the problem but has one problem. As I mentioned on bug 672047 comment 1, at this moment label_actor only sets a one-to-one actor-label relation. But in this case, as with the contacts, that button has more than one label. So with this patch, you will get the app causing the problem, but not the other label with the reason (in my case "not responding"). As I said, probably it would be good to add a StWidget method add/remove_label_actor and remove the property label_actor.
(In reply to comment #7) > (In reply to comment #0) > FWIW, testing it, when the dialog appears, Orca exposes all the text (including > "gedit not responding") FWIW that is because Orca presents all labels without relations as static text. (i.e. it's not that the text itself is inaccessible; just that the lack of relation causes it not to be presented when the button gets focus). Anyhoo, thanks for the patch.
(In reply to comment #8) > This patch solves the problem but has one problem. As I mentioned on bug 672047 > comment 1, at this moment label_actor only sets a one-to-one actor-label > relation. But in this case, as with the contacts, that button has more than one > label. > > So with this patch, you will get the app causing the problem, but not the other > label with the reason (in my case "not responding"). I'm probably being naive, but as StButton is a container, can't you descent the actor hierarchy?
(In reply to comment #10) > (In reply to comment #8) > > This patch solves the problem but has one problem. As I mentioned on bug 672047 > > comment 1, at this moment label_actor only sets a one-to-one actor-label > > relation. But in this case, as with the contacts, that button has more than one > > label. > > > > So with this patch, you will get the app causing the problem, but not the other > > label with the reason (in my case "not responding"). > > I'm probably being naive, but as StButton is a container, can't you descent the > actor hierarchy? AFAIR, in some cases Orca does a workaround like that: assume that any label that it is a child of a <insert_specific_role_here> in a specific situation is labelling that object. Taking into account the growing amount of manual assigment of label_actor on gnome-shell js code, now and then I also start to think if there is any way to automatize/generalize that situation. And it would be possible to implement on StButton the workaround I mentioned. Anyway, I think that it is not possible to totally automatize the labelling: a) We can't assume that any child label is labelling a container, because that could lead to something like this: panel->button->button_label Using this general rule, panel will be also labelled with button_label and Orca will expose that label twice. As a general rule, when the focused object changes, and his container also changes, if both button and container has names, orca exposes both. Example: on the overview if you start to navigate on the searchresult, if you change to a item in a different category (so Orca could expose something like "SETTINGS panel Color push button") b) We can't assume that a child label of a role Button is labelling the container, because in some cases, StButton is being used as a container of the real button, so we could get stuck in something similar to a) Example: searchDisplay.SearchResult c) AFAIR, in some cases the label is not a child but a sibling, so having the property label_actor (that internally creates the ATK label relationship) would be still required. Anyway, FWIW, some automatization is already in place. The property StButton.label it is properly exposed as the button name/label. This is a ideal situation, as we are not adding specific a11y code, but using a property of the object. But this property is not used in a lot of cases. I guess that this is done in order to have more control on that label (position, color, etc). PS: while writing this comment, I'm wondering if in some of those cases it is really needed to use a custom StLabel on js code instead of StButton.label
Review of attachment 215725 [details] [review]: This makes sense to me.
Patch at comment 8 committed, but not closing the bug yet as ideally this should use two labels (bug 682523)
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.