GNOME Bugzilla – Bug 681528
universal access menu issues
Last modified: 2021-07-05 14:09:33 UTC
I've noticed a couple of issues with the universal access menu. I did an informal user test yesterday and something pretty interesting popped up. The tester was really confused by the menu. Thought it was for personalization because it had a cute little person on it. And had no idea what any of the stuff in the menu was for. I think contrary to what we hoped this menu has not proven useful for most people and has a very prominent position in the UI. I suspect there are good reasons why the number two most popular extension (after adding back power off - which we also fixed) is "Remove Accessibility". Now just removing the menu is also contrary to our goals of making the experience universally accessible. One idea is to always offer the menu at the sign in screen and only offer it by default in the session if it was actually needed to sign in. This may not cover every case since some of the items are needed at different times depending on circumstance. So we may be able to do two things to help with that. First, make most of the important items available on demand automatically or via hotkeys or gestures for when the interface cannot be used/seen. For instance, the on screen keyboard should just work if there is no available keyboard device and text input is needed. Or any of the so-called accessx features should be available via the standard gestures. We may also want to show the menu when any of these features are enabled. To indicate they are on and to allow the user to turn them off. Second, we can offer to show the menu all the time as an option in the universal access settings.
I've observed the same issue described in the bug report. (In reply to comment #0) ... > One idea is to always offer the menu at the sign in screen and only offer it by > default in the session if it was actually needed to sign in. This may not cover > every case since some of the items are needed at different times depending on > circumstance. So we may be able to do two things to help with that. ... Could work.
Created attachment 221039 [details] [review] AccessibilityMenu: try to hide when not needed Hide the a11y menu when it's sure that it's not needed. The following operations are available to show it: - enable any of its options in the control center - enable a11y keyboard shortcuts in the control center - have any of the a11y features enabled (currently, only AccessX) before login Once the menu is shown, it's kept visible for the duration of the session, on the assumption that it was shown for a reason and it might be useful again. This is just part of the design, but I'd consider it an improvement over the current situation, and should mitigate the need for extensions.
Nice work! (In reply to comment #2) > Once the menu is shown, it's kept visible for the duration of the > session, on the assumption that it was shown for a reason and it > might be useful again. > > This is just part of the design, but I'd consider it an improvement > over the current situation, and should mitigate the need for extensions. I think I'm ok with this if we can make it work. But I do think it requires us to have a way to hide the menu again manually since session lifetimes are *long*. If I'm just playing around with stuff and it the menu appears I may be confused about how to make it go away again. Maybe we should just have a way to hide the menu from within the menu itself? But that might have the reverse problem. How do I get the menu back? The advantage of having the option in the system settings is that it is going to always be there. The question becomes what kind of control should it be? If the menu is displayed automatically we can't really call the option "menu: on/off". And can't call it "[x] Always show menu". And it might be weird to have "Hide menu". So, what can we do?
This menu has been causing problems for the new lock screen also. Doing user testing, my research participants were often drawn to the menu, thinking it was useful to them when it wasn't. I'd like to only show the universal access menu in the login screen, and not when the screen shield is in place. Maybe we could add "[x] Show universal access menu in top bar" to the universal access system settings panel?
(In reply to comment #2) > Created an attachment (id=221039) [details] [review] > AccessibilityMenu: try to hide when not needed > > Hide the a11y menu when it's sure that it's not needed. The following > operations are available to show it: > - enable any of its options in the control center > - enable a11y keyboard shortcuts in the control center > - have any of the a11y features enabled (currently, only AccessX) > before login Well, I thought that the idea of the universal access menu was make it easy to activate some options (a kind of replacement for shortcuts). AFAIU, with this change it will appear if you go through the control center to activate "something a11y-related". I have the feeling that with this change the universal access menu will became useful just to deactivate something. IMHO, the problem is the initial assumption "Hide the a11y menu when it's *sure* it's not needed". As William Jon MacCann said at comment 0, the circumstances can change in each case, so implementing a "sure" heuristic deciding this could be hard. If someone asks my personal opinion, I'm personally not against the "Remove accessibility" extension (except that extension icon, that it is somewhat disturbing). But this is because in general I think that it is a good idea to allow a way to hide/unhide the status icons (ie: having that I would personally hide the bluetooth status menu). But this is just a preference, and obviously don't solve the problem pointed at comment 0 of people not knowing what that menu is for.
(In reply to comment #5) ... > Well, I thought that the idea of the universal access menu was make it easy to > activate some options (a kind of replacement for shortcuts). ... It would be useful to know if there are any cases where a11y options are frequently toggled on and off.
From bug 640190 comment 1, but probably they were theorical: > - Trying to use a laptop at the beach in bright sunshine - turn on high contrast > - Showing something on your computer to a older friend with not so good vision > - use Zoom or Large Text (as a matter of fact I happen to use Zoom regularly, but not for a11y, just to check for pixel preciseness)
Created attachment 225938 [details] [review] SessionMode: look up panel contents in GSettings for the user session We already keep the model of the panel as a list of widget IDs in SessionMode, from that to storing it in GSettings the leap is small, and it will allow various customization in the tweak tool, as well as obsoleting extensions such as remove accessibility and frippery move clock. EXPERIMENTAL and not for 3.6.1, just to get the feeling. If the previous patch tried to be clever and hide when a11y is not asked for, this one simply gives the full power to the user, through the tweak tool (TBD).
Created attachment 228196 [details] [review] Add 'hide-accessibility' setting that hides accessibility in the user session Some users may feel annoyed and distressed by the accessibility menu. Allow these users a simple and effective way to hide it with a GSettings key.
Me, Jon and Jimmac discussed this issue the other day. I think we agreed with Jon's original proposal here: * always show the accessibility menu in the login screen * display the accessibility menu in the session if: - accessibility features are used to login, or if - accessibility features are active This requires two additional changes: * the main accessibility features can be activated using keyboard shortcuts, and * provide an option in the accessibility panel to configure the display of the system indicator [1] [1] Providing the options: always show, show when in use, never show
(In reply to comment #10) > * provide an option in the accessibility panel to configure the display of the > system indicator [1] At the accessility panel or at the universal access settings? > > [1] Providing the options: always show, show when in use, never show From your words I understand that the current behaviour is "always show" and the planned default value would be "show when in use", right?
(In reply to comment #11) > (In reply to comment #10) > > > * provide an option in the accessibility panel to configure the display of the > > system indicator [1] > > At the accessility panel or at the universal access settings? In the Universal Access panel, which is part of System Settings. > > [1] Providing the options: always show, show when in use, never show > > From your words I understand that the current behaviour is "always show" and > the planned default value would be "show when in use", right? Right.
(In reply to comment #10) > This requires two additional changes: > * the main accessibility features can be activated using keyboard shortcuts, > and > * provide an option in the accessibility panel to configure the display of the > system indicator [1] > > [1] Providing the options: always show, show when in use, never show Currently, there are key bindings for Zoom and screen reader, and there is a toggle for 'trigger keyboard a11y features with the keyboard' which enables things like "hold shift for 8 seconds to turn on slow keys" or "hit shift 5 times in a row to turn on sticky keys". The zoom and screen reader keybindings are not bound by default, and the 'trigger kbd a11y' toggle is off by default. Is that enough ? Having an enable-osk keybinding would be moronic, I think... We could investigate whether other platforms have default keybindings for zoom and screen reader that we could adopt.
(In reply to comment #4) > Maybe we could add "[x] Show universal access menu in top bar" to the universal > access system settings panel? Allan, how should this look, when the setting is actually a tristate ?
(In reply to comment #0) > For instance, the on screen keyboard should just work if there is no available > keyboard device and text input is needed. I always hated this universal access settings in the top panel and used to use that extension to remove the menu item, Until, one fine morning my keyboard stopped working. I cannot even login as it needs my password. One of my friends had a spare USB keyboard which I used temporarily. In short, I will never ever remove that icon from the panel again. My point is no one can predict these kind of situations and removing it can have an usability impact in situations when someone needs accessibility. Accessibility icon is most needed when it is difficult to access those settings. I also in full support of having the onscreen keyboard when no keyboard detected or keyboard do not seem to work properly (another bug may be?).
(In reply to comment #15) > I also in full support of having the onscreen keyboard when no keyboard > detected or keyboard do not seem to work properly (another bug may be?). We should definitively do that and yes, that's a different bug (not sure whether g-s or g-s-d is more appropriate)
Thats bug 677106
(In reply to comment #14) > Allan, how should this look, when the setting is actually a tristate ? Jon has done some new wireframes: https://live.gnome.org/Design/SystemSettings/UniversalAccess
I've seen those, but a) its a switch, which doesn't work for a tristate, and b) I'm more interested in fitting this setting into the existing panel, not a wholesale redesign
There is no way to fit it in the current panel. What tristate are you referring to?
(In reply to comment #20) > There is no way to fit it in the current panel. What tristate are you referring > to? At comment 10 Allan Day said: (In reply to comment #10) <skip> > * provide an option in the accessibility panel to configure the display of the > system indicator [1] > > [1] Providing the options: always show, show when in use, never show Three options. As mclasen is saying this seems a tristate and not a switch.
Created attachment 228943 [details] mockup seems to fit ?
(In reply to comment #20) > There is no way to fit it in the current panel. What tristate are you referring > to? I think that the three states we previously discussed were: "always show", "show when in use" and "never show". However, never show doesn't seem like terribly good idea, so a switch could work here. (In reply to comment #22) > Created an attachment (id=228943) [details] > mockup > > seems to fit ? Functionally it works. I'm not sure whether it is too prominent...
Sure there is whitespace in various places in the dialog but the option doesn't work there for a few reasons. Perhaps the primary reason is that this is where we put the "disable panel" switches like airplane mode and the panel is locked things. It is very confusing to put something that looks just like those but behaves nothing like those in the same place. Another reason is that this option is a bit confusing to begin with and we'll likely need a bit of text to explain it. I don't think I've added that to the mockups yet though. Regarding tristate, I don't think we need one.
If a tristate is not needed, can we get a clear definition of what the 2 states of the switch are supposed to do ? Is it this ? When always-show-a11y is on, show the a11y menu, regardless of whether ATs are in use or not. When always-show-a11y is off, only show the a11y menu when ATs are in use. Or this ? When hide-a11y is on, never show the a11y menu. When hide-a11y is off, only show the a11y menu when ATs are in use. Once we get that clarified, we can perhaps move ahead with writing a shell patch that implements the functionality, and avoid blocking on the panel redesign for that part at least.
First, I think we should always show the menu in the login screne. I think there are two workable approaches here. 1. Show the menu if you've ever enabled any of the features Then offer an option in the menu "Menu [on/off]" 2. Show the menu only when any a11y features are on And hide the menu when they are turned off. Toggling frequently can be done with hotkeys or gestures in both cases. I lean towards 2.
Option 2 seems preferable to me too. I can't think of a nice way to present an option to toggle the menu, and this seems consistent with the idea of system status.
Created attachment 236821 [details] [review] AccessibilityMenu: try to hide when not needed Hide the a11y menu when it's sure that it's not needed. The following operations are available to show it: - enable any of its options in the control center - enable a11y keyboard shortcuts in the control center - have any of the a11y features enabled (currently, only AccessX) before login Once the menu is shown, it's kept visible for the duration of the session, on the assumption that it was shown for a reason and it might be useful again. Rebased on master.
Created attachment 236826 [details] [review] AccessibilityMenu: hide when not needed Tie the menu visibility to having at least one a11y feature enabled. This one instead is the bidirectional option: it shows when needed, and hides when not needed.
(In reply to comment #29) > Created an attachment (id=236826) [details] [review] > AccessibilityMenu: hide when not needed > > Tie the menu visibility to having at least one a11y feature enabled. > > This one instead is the bidirectional option: it shows when needed, > and hides when not needed. Yes! Let's go with this one.
Ok. Did you test it / it the implementation fine?
I tested and it works as expected. Code looks good. While waiting I wrote essentially the same thing.
This doesn't keep it visible during the gdm greeter. My strategy was to have two panel menu items: "a11y" and "a11y-maybe", where the hiding logic would go in the subclass.
Created attachment 236832 [details] [review] AccessibilityMenu: hide when not needed Tie the menu visibility to having at least one a11y feature enabled. Having two classes might be cleaner, but this one is definitely simpler.
Review of attachment 236832 [details] [review]: I still think the two-classes approach is better... ::: js/ui/status/accessibility.js @@ +79,3 @@ + + if (Main.sessionMode.isGreeter) { + this.actor.show(); What would hide this in the first place? @@ +80,3 @@ + if (Main.sessionMode.isGreeter) { + this.actor.show(); + return; JS will warn if you do tihs and then "return false;" at the end. @@ +90,3 @@ + }, + + _queueSyncMenuVisibility: function() { We're queueing an idle with no purpose in the greeter case.
Created attachment 236833 [details] [review] AccessibilityMenu: hide when not needed Tie the menu visibility to having at least one a11y feature enabled. Ok, if you insist with the two classes.
Review of attachment 236833 [details] [review]: Yeah, I like this better.
Attachment 236833 [details] pushed as c462111 - AccessibilityMenu: hide when not needed
Thanks guys!!
As it stands, if the user needed to use the OSK, the zoom, large print or high contrast in the greeter, they won't have the ability to change those in the session as that data isn't passed through from the greeter to the session. GDM used to pass some information about the selected keyboard layout to the session. We should bring back something like that to make sure that features enabled in the greeter are enabled in the session as well. (I understand you wanted to get this in before UI freeze, but it still needs refining before the release)
It would be possible to set an environment variable such as GDM_A11Y_OPTIONS, which the gnome-settings-daemon/a11y-keyboard or gnome-settings-daemon/a11y-settings would read and apply to GSettings. Not easy (needs changes in gdm to pass the variable through), but I can't think of better alternatives.
might be better to use root window properties, otherwise we have to funnel it from settings daemon to shell to worker to settings daemon.
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.