Screenreader starts, but does not work with installer (ubiquity) in live session

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1231091

What happens when you launch the live image directly to the desktop, and enable accessibility from the F5 accessibility menu?

I was able to use the terminal as you described, although I had to do so after using alt tab to make sure it was switched to. I think Orca works better when nautilus properly loads, and there is a desktop frame for point of reference. THings behave correctly when I booted the live image directly to the desktop, and enabled accessibility from the boot menu.

Yes ubiquity is not accessible, when being run from the live session, but that is moreso an ubiquity problem, because Orca is able to work with applications if they are running as root, including their GUI.

Moving to ubiquity for now, and I'll try digging a bit further next week.

Still hitting this on the rc image for 20131016 - no sounds from ubiquity.
using the f5 menu, it works in ubiquity, but I still hit bug #1154345

Status changed to 'Confirmed' because the bug affects multiple users.

I hit this twice out of 3 attempts with 20131016.1 i386 image.

Issue exists in 20.10 ISO as well. Currently testing 20201021.2 ISO. When installer started, it only reads installer started but there after no instruction to navigate. screen-reader installation testcase fails.

I'm able to recreate this in hirsute and focal. I tested on 2 different machines and saw this behavior 3 out of 3 times I tried it.

because ubiquity is priviledged sudo process for which we prohibit the user permissions-only screenreader to read, as if ubiquity, when launched from live session should kill screenreader, and relaunch it. Or like run its own instance.

Still fails as tested with 20210304 ISO of Ubuntu MATE.

1) No audio feedback during initial language selection, before going into live session. If somebody wants language other than English, pressing up/down arrows doesn't read the language name.
2) When in live session, once installer starts, no audio feedback.

I can reproduce this problem (exactly what is described in comment #10) with the 20210324 daily build of Ubuntu MATE. The problem *does not* exist in the 20210324 daily build of regular Ubuntu.

The only difference I see here is that when you start an install and you're presented with the Install screen, the regular Ubuntu says "Install" and the Ubuntu MATE one says "Install (as superuser)".

So why does the MATE installer use superuser privs and is this absolutely necessary?

@hellsworth, nice catch. That could be an issue.

As you noticed, bug #1874283 is duplicate of this. I'll try to combine the two with current status, to best of my understanding and testing.

1) When we hear the sound, we can start orca screen reader with Super+Alt+s. No audio feedback for the screen, language selection or choosing one of 'Try Ubuntu (MATE)' or 'Install Ubuntu (MATE)'.
 - Current status: Audio feedback available in Ubuntu default but not in Ubuntu MATE.

2) Some commented that if they boot into efi mode the screen reader installer worked fine but had problem only in BIOS mode.
 - Current status: Both modes have problems (definitely 20.10 onwards).

3) Some commented that if they used live mode (Try Ubuntu), the screenreader worked fine for installation but not if they choose installer directly (Install Ubuntu).
 - Current status: Screen reader does not work if installer started from inside live mode both in Ubuntu default and Ubuntu MATE.

4) On the other hand, we were suggested quite the opposite; that it will work fine if we select installer directly but not if we select live mode first.
 - Current status: Screenreader works when starting installer directly only for Ubuntu default. No luck on Ubuntu MATE.

5) Screen reader works if we start assistive technology in live mode (Thanks @artemiy-22).
 - Current status: This works in Ubuntu MATE (could not get it to work on Ubuntu 20.04).

Following are steps to make screenreader install work in Ubuntu MATE.
  a) Select 'Try Ubuntu'
  b) Once the desktop loads, open 'Assistive Technologies Preferences' and check 'enable assistive technologies'. This I had to do even when screenreader was on (Alt+Super+s).
  c) Choose 'Close and Log Out'. (Just using 'Close' does not work, we have to end the current session).
  d) Select 'Live session user' in the login screen and hit return (no password).
  e) After we re-login and start the screenreader, we can use installer in blind user mode.

It appears that ubiquity is being invoked via sudo for all flavours, including Ubuntu. Here is the Exec= line from ubiquity.desktop:

```
#use sh because pkexec is broken under xfce/lxce http://pad.lv/1193526
Exec=sudo --preserve-env=DBUS_SESSION_BUS_ADDRESS,XDG_RUNTIME_DIR sh -c 'ubiquity gtk_ui'
```

This bug was fixed in the package ubuntu-mate-settings - 21.04.7

---------------
ubuntu-mate-settings (21.04.7) hirsute; urgency=medium

  * Disable LightDM manual login. (LP: #1895875)
  * Enable assistive technologies in the live session (LP: #1231091)

 -- Martin Wimpress <email address hidden> Wed, 07 Apr 2021 09:30:09 +0100

Regarding @hellsworth's observation (post # 11):

Though this observation may well lead us down the correct path, I strongly believe both run as the superuser. Here's why:

For the record, the MATE desktop's window manager is Marco; the "window manager" on stock Ubuntu is Mutter since stock Ubuntu uses the GNOME desktop. Another thing to note is that stock Ubuntu tends to use Wayland by default, whereas Ubuntu MATE exclusively uses X11 (mainly because the MATE applications don't work very well on Wayland yet).

Marco adds the " (as superuser)" suffix to the end of windows which are owned by the superuser. The Marco code which adds the suffix is located on lines 486-491 in the source file `src/core/window-props.c` (see https://github.com/mate-desktop/marco/blob/master/src/core/window-props.c#L486-L491):

             if (window_owner==0)
               {
                 /* Simple case-- don't bother to look it up. It's root. */
                 *target = g_strdup_printf (_("%s (as superuser)"),
                                            title);
               }

I was going to look up whether Mutter has a similar block of code for the function, but I discovered I didn't need to: On stock Ubuntu, the maybe-ubiquity screen uses just a plain old, client-side-decorated header bar, which bypasses the window manager's own decorations. I can prove it since this screenshot (https://phoenixnap.com/kb/wp-content/uploads/2021/04/choose-keyboard-layout-for-ubuntu-20.04.png) shows Ubiquity's title bar without the menu button on the left side of the window title bar; the menu icon (which is a group of three white horizontal lines) always appears with the default Mutter settings if Mutter draws the window title. Note that Mutter never draws the window title on Wayland.

So in other words, just because one says it's run as the superuser and the other doesn't say it does not mean that the other is not run as the superuser. To find the real answer, we'd have to boot up a stock Ubuntu to the maybe-ubiquity screen, press Ctrl-Alt-F1 to go to a console, log in, and then use `ps` to find out who owns the `ubiquity` process.

However, furthermore it would be a good experiment to find out if the Wayland / X11 difference is the culprit. I wonder if any accessibility information is communicated over the X protocol, or if it's all done via D-Bus?

It's been well over a month since I last reported on this, so I think it's fine time I reported about the latest on the subject.

My above comment was mostly correct and slightly wrong. Interestingly, stock Ubuntu 21.10 does not use Wayland (on my setup, at least, with Intel integrated graphics); it uses X11, just like Ubuntu MATE does. But interestingly, Ubiquity on stock Ubuntu starts the *GNOME Shell*, whereas Ubiquity on Ubuntu MATE only starts Marco, a generic Ubiquity top panel (which is supposed to be stocked with indicators, but Ubiquity's panel only works with Unity indicators and not Ayatana indicators), the MATE Settings Daemon, and a handful of other programs.

Furthermore, like I suspected, both Ubuntu and Ubuntu MATE start the Ubiquity greeter as root, except their *effective* user IDs are both the respective live session users (`ubuntu` and `ubuntu-mate`, respectively). The latter is done probably to allow communication over D-Bus, because my experiments show that if the process' effective UID is not 999 (the live session user), neither version of Ubiquity will interact with the screen reader.

Here's the proof. The first snippet was taken on an Ubuntu 21.10 system (that took me eons to download); the second is from an Ubuntu MATE 21.10 system.

Ubuntu:

   RUSER EUSER PID PPID COMMAND
   ubuntu ubuntu 1948 1941 /usr/bin/pipewire
   ubuntu ubuntu 1949 1941 /usr/bin/pipewire-media-session
   ubuntu ubuntu 1950 1941 /usr/bin/pulseaudio --daemonize=no --log-target=journal
   ubuntu ubuntu 1953 1941 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
   ubuntu ubuntu 1966 1941 /usr/libexec/dconf-service
   ubuntu ubuntu 1983 1703 /usr/libexec/gsd-a11y-settings
   ubuntu ubuntu 1986 1703 /usr/libexec/gsd-keyboard
   ubuntu ubuntu 1987 1703 /usr/libexec/gsd-media-keys
   ubuntu ubuntu 2004 1703 /usr/libexec/gsd-power
   ubuntu ubuntu 2005 1703 /usr/libexec/gsd-xsettings
   ubuntu ubuntu 2006 1703 gnome-shell --sm-disable --mode=ubiquity
   root ubuntu 2028 2009 /usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity --greeter --only
   ubuntu ubuntu 2151 2146 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
   ubuntu ubuntu 2166 1941 /usr/libexec/at-spi2-registryd --use-gnome-session

Ubuntu MATE:

   RUSER EUSER PID PPID COMMAND
   ubuntu-+ ubuntu-+ 1882 1875 /usr/bin/pulseaudio --daemonize=no --log-target=journal
   ubuntu-+ ubuntu-+ 1893 1875 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
   ubuntu-+ ubuntu-+ 1896 1875 /usr/libexec/dconf-service
   ubuntu-+ ubuntu-+ 1926 1694 /usr/bin/mate-settings-daemon
   ubuntu-+ ubuntu-+ 1927 1694 marco --sm-disable
   ubuntu-+ ubuntu-+ 1931 1694 /usr/lib/ubiquity/panel
   ubuntu-+ ubuntu-+ 1938 1694 nm-applet
   ubuntu-+ ubuntu-+ 2000 1875 /usr/libexec/at-spi-bus-launcher
   ubuntu-+ ubuntu-+ 2007 2000 /usr/...

I'm pretty sure I discovered the bug, and I think I know how to rectify it too.
Please note that this was a tricky bug to find and it made my head spin for a
while; it was only recently when I figured this out from start to end. Here's
what I know now:

I discovered that Ubiquity's greeter (`maybe-ubiquity`) starts two D-Busses:
the normal session bus, which non-root programs communicate over for
pretty much everything (including accessibility communications), and the
special accessibility bus, which is only used by root programs like Ubiquity.
The accessibility bus uses a special configuration file which allows root to
use the bus (normally root would be banned from the bus); that configuration
file is stored at /usr/share/defaults/at-spi2/accessibility.conf:

   [...]
   <policy context="default">
     <!-- Allow root to connect -->
     <allow user="root"/>
     <!-- Allow everything to be sent -->
     <allow send_destination="*" eavesdrop="true"/>
     <!-- Allow everything to be received -->
     <allow eavesdrop="true"/>
     <!-- Allow anyone to own anything -->
     <allow own="*"/>
   </policy>
   [...]

Depending on the version of Ubuntu in use, the exact application which requests
the accessibility bus in the first place (and thus the application which
requests the bus to be launched) differs. On stock Ubuntu, it is a portion of
the GNOME Settings Daemon; on Ubuntu MATE, it is consistently the Ubiquity
panel. Either way, which application starts the bus doesn't matter, as long
as an application starts it.

When an application requests the bus be started, the D-Bus daemon requests that
SystemD launches the `at-spi-bus-launcher` program. This program starts
another, separate D-Bus daemon (separate from the main session bus, that is),
and tells this new D-Bus daemon to use the aforementioned configuration file.
The bus launcher also requests that the new D-Bus daemon inform the bus
launcher about how the new D-Bus daemon can be addressed and contacted; the
applications need to know about this bus and they need to know how to
communicate on it. The D-Bus daemon tells the bus launcher how to contact it
when the D-Bus daemon has initialized itself fully.

Once the bus launcher knows how to contact the accessibility bus, the bus
launcher is supposed to set an *X11 atom* on the root window of the X session
which Ubiquity is using. The atom applied to the root window means that any
application, even Ubiquity, can quickly and easily find out how to communicate
over the accessibility bus. Here's an example of the atom:

   $ DISPLAY=":0" xprop -root AT_SPI_BUS
   AT_SPI_BUS(STRING) = "unix:abstract=/tmp/dbus-jvfzJSsTTp,guid=e1dc67ddfb5b08287b1b9676612460d8"

This means that the accessibility bus can be reached using a UNIX domain socket
(so it can be accessed only on the local system); a proper call to "bind" to
the socket at `/tmp/dbus-jvfzJSsTTp` will connect to the accessibility bus
(though the `abstract` part means that the socket is not visible in the file
system; this is a Linux-only feature, and you'll sometimes see `path` instead,
which means the socket can be viewed as part of the file system); and in order
to verify that the...

Not sure if this will help or not, but I too am having the same installer bug. Along with this, I cannot drop to a terminal and run something like gparted. I have no speech, and alt+tabbing results in Orca saying gparted as super-user. Ubuntu live images are a huge trouble-shooting tool in my day to day work, so I really hope this gets resolved soon.

Impish is still affected, tested on

Ubuntu-MATE 21.10 "Impish Indri" - Beta amd64 (20211002)

rls-ii-notfixing is very positive for users with hearing problems. Keep doing. Patch is in the bug-report.

Thanks for adding an explanation (albeit after the fact) as to why it was tagged rls-ii-incoming Norbert, I've gone ahead and uploaded Gordon's change and we should be able to get it into the RC images.

This bug was fixed in the package ubiquity - 21.10.9

---------------
ubiquity (21.10.9) impish; urgency=medium

  * ubiquity-dm: use dbus-update-activation-environment for every desktop
    environment. Thanks to Gordon N. Squash for the patch. (LP: #1231091)

 -- Brian Murray <email address hidden> Fri, 08 Oct 2021 13:04:00 -0700