GNOME Bugzilla – Bug 706391
System-status items with sliders are inaccessible
Last modified: 2013-08-22 15:22:42 UTC
Created attachment 252410 [details] pyatspi listener Steps to reproduce: 0. Launch the attached pyatspi listener in a terminal 1. Use the keyboard to get into the new system-status menu 2. Arrow amongst the items Expected results: All items would have a name or a label. Actual results: Items with sliders lack both a name and a label. Output from performing the above steps: Top Bar push button Activities toggle button Terminal menu Tue 20 Aug, 08∶32 menu Settings Menu menu UNNAMED menu item <--- (iconless) slider UNNAMED menu item <--- microphone slider UNNAMED menu item <--- brightness slider Wi-Fi menu item Battery menu item Lock push button Settings push button Lock push button Power Off push button
BTW, I'm taking a look to this bug (yes, I know that we have "assign bug", but nobody uses it).
Setting a dependency to bug 706386, because the solution to this bug would be different depending on which is the actor that will receive the focus. Right now is the menu item (so we could change the name/role on that element), but on the solution proposed at that bug, it will be the slider.
Created attachment 252624 [details] [review] Setting proper name and role for system menu sliders Note: this patch depends on the one uploaded on bug 706386, because it works under the assumption that is the slider the one that will receive the focus. Note2: this is another reason giving the focus to the slider makes sense. In this patch the element that receives a SLIDER role is (dun dun DUN) the slider. If we keep the menu item as the element that will get the focus, will mean that we would need to customize those menu items to have a SLIDER role.
Review of attachment 252624 [details] [review]: Looks good regardless of whatever strategy we eventually use. We can just put the role on the hbox as well, but we should put it on the slider too.
(In reply to comment #4) > Review of attachment 252624 [details] [review]: > > Looks good regardless of whatever strategy we eventually use. We can just put > the role on the hbox as well, but we should put it on the slider too. In my opinion the current hbox role is correct. It is working as a menu item, so role MENU ITEM is the straighforward solution. Additionally setting the slider role to the hbox too would mean that Orca (or any other AT) will find a container with a role SLIDER, that contains a child with the role SLIDER. That sounds confusing to me. More if we take into account that my plan is implment AtkValue interface only at the real slider. After all, slider was refactored in order to maintain all the slider common code there (FWIW, as I'm right now on "slider party inertia" I also plan to retake bug 648623). In any case, holding on this bug until we came to a conclusion/fix for bug 706386
(In reply to comment #5) > (In reply to comment #4) > > Review of attachment 252624 [details] [review] [details]: > > > > Looks good regardless of whatever strategy we eventually use. We can just put > > the role on the hbox as well, but we should put it on the slider too. > > In my opinion the current hbox role is correct. It is working as a menu item, > so role MENU ITEM is the straighforward solution. > > Additionally setting the slider role to the hbox too would mean that Orca (or > any other AT) will find a container with a role SLIDER, that contains a child > with the role SLIDER. That sounds confusing to me. More if we take into account > that my plan is implment AtkValue interface only at the real slider. After all, > slider was refactored in order to maintain all the slider common code there > (FWIW, as I'm right now on "slider party inertia" I also plan to retake bug > 648623). > > In any case, holding on this bug until we came to a conclusion/fix for bug > 706386 Bug 706386 was closed. With the patch, sliders have a proper name/role. Just confirmed with Joanmarie that the fact that the focused object is not the slider but the parent container (menu item), can be handled at the AT side. So closing the bug.