Screen reader isn't enabled on login screen or user session after installation

[Didier Roche-Tolomelli]

ISO 20191014

After enabling the screen reader for an installation by turning it on with the Super + Alt + s combination, the screen reader isn't enabled on GDM or on the user's session on the end session.

[Ubuntu QA Website (ubuntuqa)]

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

[Iain Lane (laney)]

Indeed :(

I just tested this on bionic too and it's broken there for me also

when did this work & where in ubiquity was it?

[Sebastien Bacher (seb128)]

How do you enable the screen reader? It's a bit similar to bug #1825112 which I fixed earlier in the cycle (verified on dailies at the time).
Also note that from the disco report, it worked previous cycle for the user session, what was missing was support for gdm (casper still copied the config to lightdm)

It could also be that enabling the accessibility from syslinux hits a different codepath from enabling it from the installer.

Also did you try from a live session or an install-only one?

[Iain Lane (laney)]

I pressed super-alt-s at the "Try Ubuntu / Install Ubuntu" stage, and then proceeded into a live session and installed Ubuntu from there.

Thanks for the casper hint. Perhaps what is missing is copying the screen-reader key. That hook is supposed to do it in some situations.

(I think Łukasz is looking into this one now.)

[Łukasz Zemczak (sil2100)]

So I looked into reproducing it to see exactly for which use-cases this bug appears.

When screen reader is enabled via isolinux, install-only mode:
 * Login screen and user session has screen reader enabled

When screen reader is enabled during the installation process using the keyboard shortcut, install-only mode:
 * Login screen and user session has screen reader disabled

I checked our disco images, and on those enabling the screen reader during installation also didn't actually enable the screen reader on the end system. So I think at least in this case there is no regression.

[Łukasz Zemczak (sil2100)]

Looking at the casper code, it seems to me that it actually was never written to properly work. The ubiquity-hooks/30accessibility hook basically only really acts on accessibility options passed via the cmdline. There is some strange code that seems to be for like a second pass for $UBIQUITY_A11Y_PROFILE, but it seems to be only set in /usr/bin/casper-a11y-enable - which is only ran if there are kernel cmdline options set.

[Łukasz Zemczak (sil2100)]

Prepared a fix for this. Apparently this got broken with our switch to gnome-shell, so it's been busted since quite a while. The fix is very simple though. Previously I was wondering why the strange UBIQUITY_A11Y_PROFILE variable handling logic was there in the casper hook - but it seems *this* was the reason!

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 20.04.2

---------------
ubiquity (20.04.2) focal; urgency=medium

  * Make sure the screen-reader-enabled setting gets passed to the target
    system (LP: #1848144).

 -- Łukasz 'sil2100' Zemczak <email address hidden> Fri, 29 Nov 2019 10:47:45 +0100