After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 681528 - universal access menu issues
universal access menu issues
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: system-status
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-08-09 15:34 UTC by William Jon McCann
Modified: 2021-07-05 14:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
AccessibilityMenu: try to hide when not needed (4.47 KB, patch)
2012-08-13 17:07 UTC, Giovanni Campagna
none Details | Review
SessionMode: look up panel contents in GSettings for the user session (3.89 KB, patch)
2012-10-06 15:39 UTC, Giovanni Campagna
none Details | Review
Add 'hide-accessibility' setting that hides accessibility in the user session (3.23 KB, patch)
2012-11-05 22:25 UTC, Jasper St. Pierre (not reading bugmail)
none Details | Review
mockup (40.01 KB, image/png)
2012-11-14 03:38 UTC, Matthias Clasen
  Details
AccessibilityMenu: try to hide when not needed (3.93 KB, patch)
2013-02-19 19:33 UTC, Giovanni Campagna
none Details | Review
AccessibilityMenu: hide when not needed (3.58 KB, patch)
2013-02-19 19:54 UTC, Giovanni Campagna
none Details | Review
AccessibilityMenu: hide when not needed (3.69 KB, patch)
2013-02-19 20:34 UTC, Giovanni Campagna
reviewed Details | Review
AccessibilityMenu: hide when not needed (5.16 KB, patch)
2013-02-19 20:51 UTC, Giovanni Campagna
committed Details | Review

Description William Jon McCann 2012-08-09 15:34:37 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.
Comment 1 Allan Day 2012-08-09 16:05:05 UTC
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.
Comment 2 Giovanni Campagna 2012-08-13 17:07:51 UTC
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.
Comment 3 William Jon McCann 2012-08-13 17:41:49 UTC
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?
Comment 4 Allan Day 2012-08-16 15:57:37 UTC
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?
Comment 5 Alejandro Piñeiro Iglesias (IRC: infapi00) 2012-08-23 09:41:18 UTC
(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.
Comment 6 Allan Day 2012-08-23 09:48:20 UTC
(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.
Comment 7 Frederic Peters 2012-08-23 10:51:11 UTC
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)
Comment 8 Giovanni Campagna 2012-10-06 15:39:24 UTC
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).
Comment 9 Jasper St. Pierre (not reading bugmail) 2012-11-05 22:25:58 UTC
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.
Comment 10 Allan Day 2012-11-06 09:51:35 UTC
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
Comment 11 Alejandro Piñeiro Iglesias (IRC: infapi00) 2012-11-06 10:16:50 UTC
(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?
Comment 12 Allan Day 2012-11-06 10:30:39 UTC
(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.
Comment 13 Matthias Clasen 2012-11-07 12:34:53 UTC
(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.
Comment 14 Matthias Clasen 2012-11-07 12:55:53 UTC
(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 ?
Comment 15 Justin 2012-11-08 15:46:38 UTC
(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?).
Comment 16 Florian Müllner 2012-11-08 17:56:42 UTC
(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)
Comment 17 Matthias Clasen 2012-11-10 00:19:34 UTC
Thats bug 677106
Comment 18 Allan Day 2012-11-12 16:11:04 UTC
(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
Comment 19 Matthias Clasen 2012-11-12 17:01:22 UTC
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
Comment 20 William Jon McCann 2012-11-13 20:47:17 UTC
There is no way to fit it in the current panel. What tristate are you referring to?
Comment 21 Alejandro Piñeiro Iglesias (IRC: infapi00) 2012-11-13 23:59:55 UTC
(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.
Comment 22 Matthias Clasen 2012-11-14 03:38:17 UTC
Created attachment 228943 [details]
mockup

seems to fit ?
Comment 23 Allan Day 2012-11-14 09:08:49 UTC
(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...
Comment 24 William Jon McCann 2012-11-14 14:29:03 UTC
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.
Comment 25 Matthias Clasen 2012-11-19 13:15:58 UTC
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.
Comment 26 William Jon McCann 2013-02-19 18:31:44 UTC
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.
Comment 27 Allan Day 2013-02-19 18:43:13 UTC
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.
Comment 28 Giovanni Campagna 2013-02-19 19:33:03 UTC
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.
Comment 29 Giovanni Campagna 2013-02-19 19:54:52 UTC
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.
Comment 30 William Jon McCann 2013-02-19 20:03:16 UTC
(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.
Comment 31 Giovanni Campagna 2013-02-19 20:16:07 UTC
Ok. Did you test it / it the implementation fine?
Comment 32 William Jon McCann 2013-02-19 20:18:54 UTC
I tested and it works as expected. Code looks good. While waiting I wrote essentially the same thing.
Comment 33 Jasper St. Pierre (not reading bugmail) 2013-02-19 20:19:55 UTC
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.
Comment 34 Giovanni Campagna 2013-02-19 20:34:57 UTC
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.
Comment 35 Jasper St. Pierre (not reading bugmail) 2013-02-19 20:40:31 UTC
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.
Comment 36 Giovanni Campagna 2013-02-19 20:51:07 UTC
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.
Comment 37 Jasper St. Pierre (not reading bugmail) 2013-02-19 20:58:14 UTC
Review of attachment 236833 [details] [review]:

Yeah, I like this better.
Comment 38 Giovanni Campagna 2013-02-19 21:07:58 UTC
Attachment 236833 [details] pushed as c462111 - AccessibilityMenu: hide when not needed
Comment 39 William Jon McCann 2013-02-19 21:12:19 UTC
Thanks guys!!
Comment 40 Bastien Nocera 2013-02-21 00:03:12 UTC
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)
Comment 41 Giovanni Campagna 2013-02-21 14:35:02 UTC
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.
Comment 42 Ray Strode [halfline] 2013-03-01 18:11:08 UTC
might be better to use root window properties, otherwise we have to funnel it from settings daemon to shell to worker to settings daemon.
Comment 43 GNOME Infrastructure Team 2021-07-05 14:09:33 UTC
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.