NixOS declarative accessibility options vs. GNOME runtime settings: where should per-user screen reader state live?

Ownership split

Per-user screen-reader state belongs in the user's GNOME runtime settings, not in NixOS system options. Declare it through Home Manager's dconf.settings. NixOS options such as services.xserver.desktopManager.gnome.accessibility.enable and programs.screenreader.enable should only ensure that Orca, speech-dispatcher, and AT-SPI services and packages exist at the system level.

Why runtime settings are the source of truth

GNOME stores the screen-reader toggle in the user's dconf database under org.gnome.desktop.a11y.applications screen-reader-enabled. When a user enables Orca in GNOME Settings or runs gsettings set ..., that write goes to the user database. NixOS activation manages system files and does not track or reconcile these per-user keys.

The likely drift cause is therefore structural: two layers write to different stores. The confirmed fact is that no supported NixOS system option currently declares per-user GNOME accessibility toggles, and Home Manager does not auto-sync with NixOS options.

Recommended configuration

1. Keep system options for services and packages only. On 23.11 or 24.05, verify exact option names and defaults with nixos-option before rebuilding, because module names and behavior are release-sensitive.
2. Declare the user toggle in Home Manager:

   dconf.settings."org/gnome/desktop/a11y/applications".screen-reader-enabled = true;

3. Apply the system configuration, then run home-manager switch. The user dconf database is rewritten so the value survives future rebuilds.
4. Verify the live state:

   gsettings get org.gnome.desktop.a11y.applications screen-reader-enabled
   pgrep -a orca
   systemctl --user status speech-dispatcher

   Note that speech-dispatcher may be socket-activated or a system service depending on the NixOS module; check the matching socket if the unit is not found.

Combining layers and detecting drift

System-level NixOS options and Home Manager settings can coexist for one user as long as responsibilities are separated: NixOS provides daemons and packages, Home Manager owns user dconf keys. Do not enable the same daemon or Orca autostart in both layers, and do not start Orca manually; the GNOME key should drive the process so state and runtime stay consistent.

To reconcile drift, compare the live value from gsettings get with the declared Home Manager value and re-run home-manager switch. Forcing the key with system dconf locks is only appropriate for kiosk-style policy, not normal per-user state, because it can fight users who need to toggle assistive technology.

Open diagnostic

One missing detail would change the recommendation: are system-level dconf locks or defaults active on this host? If they are, Home Manager alone may be overridden and the declaration must move to system dconf policy instead.