Why does the Mac accessibility keyboard turn off sticky keys?

There IS a SORT of means to pull this off...

The explanation you asked for...

See, the problem here is that MacOS treats the two as mutually-exclusive. If one is on, the other either greys out or silently disables itself. There's no supported way to make them coexist, even via plist edits or hidden defaults.

It's not a bug, it's a design guardrail baked into the UniversalAccess framework. Both features hook into the same low-level keyboard event system:

Sticky Keys intercepts modifier-key state at the hardware event level (for example, Shift toggled vs. held).

Accessibility Keyboard injects virtual key events through the same pipeline.

If both were active simultaneously, macOS would have to choose which system "owns" the modifier logic — e.g., should the sticky-state apply to on-screen taps or to physical keys? Apple's internal documentation notes that it could cause key-repeat loops or broken modifier combinations, so they hard-blocked it.

And now, a solution!

Download a (free!) copy of Karabiner Elements. This is an OUTSTANDING keyboard management tool that allows you to basically script/dictate whatever behaviors into your keyboard you like (including the virtual ones! 😀)!

Karabiner-Elements can give you "Sticky Keys–like" behavior without touching macOS's own Sticky Keys, so it won't "fight" the Accessibility Keyboard.

Here's a dead-simple setup: tap ⇧ (shift) to toggle a sticky ⇧; hold ⇧ to behave normally; tap ⇧ again (or hit Esc) to release.

Add this to the profiles[...].complex_modifications.rules inside of the ~/.config/karabiner/karabiner.json rule definitions file:

{ "description": "Tap Shift to toggle sticky Shift; hold to use Shift normally", "manipulators": [ { "type": "basic", "from": { "key_code": "left_shift", "modifiers": { "optional": ["any"] } }, "to_if_held_down": [ { "key_code": "left_shift" } ], "to_if_alone": [ { "sticky_modifier": { "left_shift": "toggle" } } ] }, { "type": "basic", "from": { "key_code": "right_shift", "modifiers": { "optional": ["any"] } }, "to_if_held_down": [ { "key_code": "right_shift" } ], "to_if_alone": [ { "sticky_modifier": { "right_shift": "toggle" } } ] }, /* Optional: tap Esc to clear any sticky Shift */ { "type": "basic", "from": { "key_code": "escape" }, "to": [ { "sticky_modifier": { "left_shift": "off" } }, { "sticky_modifier": { "right_shift": "off" } } ] } ] } 

Notes you'll care about

• sticky_modifier is a first-class Karabiner action; it supports "on" | "off" | "toggle" and works per-modifier (left/right shift key).
• This is independent of macOS Sticky Keys, so it coexists with the Accessibility Keyboard.
• Karabiner also has a built-in Sticky modifier key indicator if you want a visual cue (enable via Karabiner settings).

Note: If you're not the sort that can jive with code, or this seems too difficult/ambiguous, or you are struggling to make this work, drop a reply to my answer. I'll check back a bit later, and if you're having trouble, I'll do my best to walk you through it. Their definitions file IS a bit confusing at first blush. ❤️

Edit: I just noticed you're a new user, here (welcome!). If you aren't yet able to comment on answers, just mod your original question; I'll check that too.

---

Clarifying for @Linc Davis

(Bunch of technical mumbo-jumbo below; not necessary to understand to implement the solution above)

On UniversalAccess

UniversalAccess is Apple's deep-down, OS-level, private (non-public, non-scriptable) framework for system accessibility features (Sticky/Slow Keys, Accessibility Keyboard, etc.). The switches that allow a user to interact with them live inside of the System Settings, and the only real programmatic access to same are part of their MDM ("Mobile Device Management", in this case referring to a domain admin's ability to remotely administer the devices, NOT iOS).

This is why, incidentally, one cannot toggle the settings via a simple OSAScript command (the FIRST thing I tried to help OP, since usually those are SESSION-scoped, not plist-scoped, so can sometimes bypass similar restrictions. S'why one can toggle Dark Mode using OSAScript without actually changing the System Setting).

On Karabiner's End-Run of the Conflict

Karabiner is a third-party software that acts as an intermediary input transformer. It basically creates a virtual HID ("Human Input Device") that intercepts the events from the physical keyboard and modifies them in-flight. Apple's Accessibility Keyboard is ALSO a virtual HID, but, due to its implementation at the UniversalAccess layer (see "deep-down", above), its input events APPEAR identical to a physical 'board.

Karabiner's Virtual HID Keyboard is a DriverKit system extension. It sits "above" that deep-down layer that macOS treats like actual hardware, intercepting inputs from the "real" keyboard, transforming them, then "releasing" them to the rest of the OS. Moreover, the "sticky_modifier" script I provided leverages Karabiner's own feature (tap to toggle, etc.) to simulate the behavior of Sticky Keys. Since Apple's Sticky Keys remains OFF, there is no internal conflict.

...Does that help?