3

I still don't know why KDE Accessible / the screenreader starts automatically and how to conveniently prevent it via KDE's options.

In the latest version of KDE that's used by KDE neon I could not find a a way to remove the package to make sure it's not getting started.

I'd like to remove or properly disable it because:

  • I don't need it
  • it only increases the attack surface of the machine
  • having a screenreader enabled might be a privacy-related security problem

In Debian10/KDE I sued to be able to simply remove kaccessible by running sudo apt-get purge kaccessible.

But it looks like it's not installed as a separate package in KDE Plasma 5.20 of the latest KDE neon (no package kaccess or similar is installed). Furthermore, I found that even on Debian 10 kaccess still starts automatically even after purging kaccessible: dpkg -S /usr/bin/kaccess says that it's now part of plasma-desktop and I can't find a way to prevent it from autostarting.

I already removed it from autostarts in the settings "Autostart" but it's still starting automatically (check whether it's running after booting with the process manager / System Monitor).

One workaround seems to be running sudo chmod -x /usr/bin/kaccess (see its location with which kaccess) in the same way as for KDE connect which is similarly annoyingly uncontrollable by the user.

1
  • 1
    Agree! I use localised version of KDE. Never seen KDEconnect neither Kaccess in the SystemSettings. I see it as persistent problem in compile of KDE component. Any server should be controlled by user. The other way ends in microsoftisation.
    – schweik
    Nov 6, 2020 at 15:57

1 Answer 1

1

Preamble

As one might expect from a piece of holdover software from the Plasma 4 days, KAccess also predates the existence of systemd, and is still yet to receive a thorough enough porting effort to integrate it with all of the current desktop infrastructure. In fact I'm a little amazed at the fact that when I saw your question and thought "Oh! I think I know just what the answer is to this one!" and pulled down a Yakuake window, my first ls command was to exactly the right directory despite it probably being 6-8 years since I fell victim to this issue myself. Here's the exact command I invoked and its output:

$ ls -lFAhkp /etc/xdg/autostart/kaccess.desktop

  rw-r--r--   1   root   root      2 KiB   Thu Jan 21 13:01:43 2021    kaccess.desktop

The Perpetrator is found

That file right there is the source of all your frustrations, I'm sorry to report. And as satisfying as I know it would be to rm -f that thing to the gates of Hades, I'm going to have to counsel you in an altogether different direction. The reason is thus...

The file's recent mtime alerted me to the fact that it wasn't cruft, but most likely still a constituent of a current package within the KDE framework. In fact I soon discovered that it's not in just any package, but none other than plasma-desktop itself! This means that if you deleted it, the next time you used the package manager to update your system following a new set of plasma-* packages being issued, the file would be right back where it was. Luckily the legitimate, "According to Hoyle" solution is a quick one, at least.

Always consult an ancient scroll before attempting to slay a dragon

The whole autostart folder thing is yet another of the Freedesktop.org XDG (Cross-Desktop Group) Specifications, aptly named Desktop Application Autostart, and this little nugget is tucked inside the Implementation Notes paragraph:

If an application autostarts by having a .desktop file installed in the system wide autostart directory, an individual user can disable the autotomatic start of this application by placing a .desktop file of the same name in its personal autostart directory which contains the key Hidden=true.

Earlier in the specification, the section on Autostart Directories states:

If $XDG_CONFIG_HOME is not set the autostart directory for a user account is ~/.config/autostart.

If $XDG_CONFIG_DIRS is not set the system-wide autostart directory is /etc/xdg/autostart.

The conquering hero returns

All that being clear, this would be my approach to the situation, executed in a sufficiently sophisticated shell such as Bash or Z Shell to accommodate the.conditional variable expansion shown.

  1. Ensure the autostart directory for your user account does, in fact, exist.

    mkdir -pv "${XDG_CONFIG_HOME:-~/.config}/autostart"

  2. Banish a copy of the offending plasma-desktop file to rot there for all eternity.

    cp -iv /etc/xdg/autostart/kaccess.desktop "${XDG_CONFIG_HOME:-~/.config}/autostart"

  3. After deleting any existing lines from the file that set a value for the Hidden key, use the spell from the scroll to curse it with a lifetime of impotence.

    grep -Eq 'Hidden\s*?=' "${XDG_CONFIG_HOME:-~/.config}/autostart/kaccess.desktop" &&
      sed -Ei '/Hidden[[:blank:]]*?=/d' "${XDG_CONFIG_HOME:-~/.config}/autostart/kaccess.desktop";
    echo "Hidden=true" >>"${XDG_CONFIG_HOME:-~/.config}/autostart/kaccess.desktop"
    

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.