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

Bug #1231091 reported by Paul Larson
This bug affects 16 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Fix Released
Brian Murray
Fix Released
Brian Murray
ubuntu-mate-settings (Ubuntu)
Fix Released
Martin Wimpress 
Fix Released
Martin Wimpress 

Bug Description

Image: 20130925

I started the image and let it boot to the gui selector for live session or install only. When the drum sound played, I pressed ctrl-s to start the screen reader and heard the familiar "screenreader on" sound, and it read the options to me. From there, I started the live session, and went into the installer, but orca would not read any of the screens. I also started a terminal window and noticed that it says "window" when I move the mouse over the unity launcher icon, and "unity dash" when I click on it, but nothing in the terminal is read to me either. So I don't think this is limited to just ubiquity.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: gnome-orca 3.9.92-0ubuntu1
ProcVersionSignature: Ubuntu 3.11.0-8.15-generic 3.11.1
Uname: Linux 3.11.0-8-generic x86_64
ApportVersion: 2.12.4-0ubuntu1
Architecture: amd64
CasperVersion: 1.336ubuntu1
Date: Wed Sep 25 14:04:20 2013
LiveMediaBuild: Ubuntu 13.10 "Saucy Salamander" - Beta amd64 (20130925)
MarkForUpload: True
PackageArchitecture: all
SourcePackage: gnome-orca
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
Paul Larson (pwlars) wrote :
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

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

A list of all reports related to this bug can be found here:

tags: added: iso-testing
Paul Larson (pwlars)
description: updated
Revision history for this message
Luke Yelavich (themuso) wrote : Re: [Bug 1231091] [NEW] Screenreader starts, but quits working in live session on install

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.

affects: gnome-orca (Ubuntu) → ubiquity (Ubuntu)
Revision history for this message
Paul Larson (pwlars) wrote : Re: Screenreader starts, but quits working in live session on install

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Revision history for this message
Para Siva (psivaa) wrote :

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

Changed in ubiquity (Ubuntu):
importance: Undecided → High
milestone: none → ubuntu-14.04
Mathew Hodson (mhodson)
Changed in ubiquity (Ubuntu):
milestone: ubuntu-14.04 → none
tags: added: a11y
Revision history for this message
Sai Vinoba (saivinob) wrote :

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.

summary: - Screenreader starts, but quits working in live session on install
+ Screenreader starts, but does not work with installer (ubiquity)
summary: - Screenreader starts, but does not work with installer (ubiquity)
+ Screenreader starts, but does not work with installer (ubiquity) in live
+ session
Revision history for this message
William Wilson (jawn-smith) wrote :

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.

tags: added: rls-hh-incoming
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

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.

tags: added: hirsute rls-hh-notfixing
removed: rls-hh-incoming
Changed in ubiquity (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Sai Vinoba (saivinob) wrote :

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.

Revision history for this message
Heather Ellsworth (hellsworth) wrote :

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?

Revision history for this message
Sai Vinoba (saivinob) wrote :

@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.

Changed in ubuntu-mate-settings (Ubuntu):
status: New → In Progress
importance: Undecided → High
assignee: nobody → Martin Wimpress  (flexiondotorg)
Revision history for this message
Martin Wimpress  (flexiondotorg) wrote :

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
Exec=sudo --preserve-env=DBUS_SESSION_BUS_ADDRESS,XDG_RUNTIME_DIR sh -c 'ubiquity gtk_ui'

Changed in ubuntu-mate-settings (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ubuntu-mate-settings (Ubuntu):
status: Fix Committed → Fix Released
Norbert (nrbrtx)
Changed in ubiquity (Ubuntu):
status: Triaged → Confirmed
Changed in ubiquity (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Gordon N. Squash (thesquash) wrote (last edit ):

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

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

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 ( 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?

Norbert (nrbrtx)
tags: added: impish
removed: saucy
Revision history for this message
Gordon N. Squash (thesquash) wrote :
Download full text (5.6 KiB)

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 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:

   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/...


Revision history for this message
Gordon N. Squash (thesquash) wrote (last edit ):
Download full text (7.9 KiB)

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="*"/>

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...


Revision history for this message
Guy Schlosser (guyster) wrote :

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.

Revision history for this message
Norbert (nrbrtx) wrote :

Impish is still affected, tested on

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

tags: added: rls-ii-incoming
tags: added: rls-ii-notfixing
removed: rls-ii-incoming
Revision history for this message
Norbert (nrbrtx) wrote :

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

Revision history for this message
Brian Murray (brian-murray) wrote :

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.

Changed in ubiquity (Ubuntu Impish):
assignee: nobody → Brian Murray (brian-murray)
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu Impish):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.