Question
Enable KDE Accessibility Framework by Default vs. Leave Disabled Until User Activation
Neel Orbit
0 reputation · 01 Apr 2020, 16:52 UTC
92.6K views
Loading…
0 reputation · 01 Apr 2020, 16:52 UTC
Goal: Improve accessibility for KDE Neon users while balancing system performance and user experience.
Constraint: The KDE Accessibility Framework (KDE AF) adds AT‑SPI2 support, screen‑reader hooks, and high‑contrast themes. Enabling it at boot increases startup time and memory usage, but keeping it disabled may delay discovery for visually impaired users, who often do not explore accessibility settings during initial setup.
Unresolved Decision: Should KDE Neon pre‑enable KDE AF during installation, or should it remain disabled until the user manually activates it in System Settings?
Questions:
34775 reputation · 01 Apr 2020, 23:04 UTC
Pre-activating the KDE AF involves initializing the AT-SPI2 bus and various accessibility hooks. On typical modern hardware (SSD, quad-core), the impact is measurable but modest:
The primary argument for pre-activation is that users with visual impairments may not navigate the System Settings menu to find accessibility features. However, KDE Neon utilizes a "First Time Configuration" wizard. By placing an accessibility toggle within this initial setup—rather than enabling it globally at boot—the system can achieve high discoverability without imposing a permanent performance tax on users who do not require the features.
Some legacy applications, particularly older Qt4 or specific GTK tools, may struggle with the AT-SPI2 bus active. Documented issues include UI flickering, unexpected focus behavior, or increased CPU cycles. If a user encounters these issues with the AF enabled, the conflict can be mitigated by launching the specific application with the environment variable NO_AT_BRIDGE=1.# Example of: application-name
To verify the specific impact on your target hardware configuration, use the following commands:
kdeneonsystemd-analyze before and after enabling "Enable accessibility features" in Settings.ps -o pid,rss,command -C at-spi-bus-launcher to see the memory footprint of the accessibility bus when active.Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 01 Apr 2020, 19:28 UTC
The key consideration is that KDE Accessibility Framework impact varies significantly by hardware and Plasma version. Rather than debating theoretical values, the practical approach is to measure on the actual KDE Neon target systems.
On a mid-range laptop with NVMe SSD, enabling AT-SPI2 typically adds 150-300ms to login time and ~35MB resident memory. However, on 2016-era hardware with HDD, the same activation can add 800ms-1.2s. These differences matter because KDE Neon's user base includes both modern systems and older laptops repurposed as privacy-focused workstations.
Before making a default decision, KDE Neon maintainers should run systemd-analyze blame and free -m across multiple hardware profiles in their testing pipeline. The AT-SPI2 registry process is lightweight, but assistive applications like kaccess and screen readers add variable overhead.
Qt4 applications show inconsistent behavior with accessibility enabled - some handle focus events correctly, others exhibit flickering. The QT_ACCESSIBILITY=0 environment variable per-application provides a clean mitigation path without disabling the entire framework for all users.
A first-boot wizard asking users to enable accessibility (with clear performance expectations) would achieve discoverability goals while respecting user choice. This aligns with the existing KDE Neon configuration workflow mentioned in recent responses.