Currently Dialogizer doesn't support keyboard navigation because "blocking" scripts don't have any way to poll the state of the keyboard. I've been hesitant to expose such an interface in the past because- implemented or used carelessly- it could easily result in decks that are unusable on less-common keyboard layouts or on devices with no physical keyboard, like a phone or tablet. This functionality can also pose problems for parity between web-decker and native-decker, since browsers reserve many keys and key combinations for themselves which webapps cannot intercept.
I have been considering the addition of some kind of low-common-denominator interface that provides the equivalent of, say, an NES gamepad (when a gamepad or joystick is available) that is mirrored by various keyboard keys (when a keyboard is available) and exposed as a "live-updating" interface like Pointer. If something like this was available, I would certainly extend Dialogizer to consider the "action button"(s) as an alternative way of advancing text prompts. Having a "Gamepad" interface would also make it easier to write action-oriented video games with Decker, which seems to be a relatively common feature request.
edit: also, for the record, browser gamepad APIs require access to a "secure context" (in short, a document delivered via https); this makes it essentially impossible for web-decker to support physical gamepads, as well as many other recent web apis with similar restrictions. It's an infuriating design constraint.