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:

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.

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.

Notes you’ll care about

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:

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.

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.

Notes you'll care about

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?

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.