Most UI decisions assume the user has a full keyboard, a mouse, and a touchscreen to work with. I didn't really think about what happens when none of that is true until I started getting messages about my Morse code translator from a different kind of user than I'd designed for — people using assistive switches, where the entire available input is a single short-press or long-press.
That constraint turned out to be a genuinely interesting design problem, and it changed how I think about input handling generally, not just for this project.
*The constraint: one bit of information, repeated
*
For someone operating a sip-and-puff switch, a cheek sensor, or a single-finger tap pad, the entire input vocabulary is binary: short signal, long signal. That's it. No modifier keys, no click-and-drag, no multi-touch gestures.
What's interesting is that this is exactly the same constraint Morse code was designed around in the first place — it's a two-symbol system by definition. So in a strange way, the "legacy" 1830s encoding turns out to be closer to an ideal fit for extremely constrained modern input hardware than most contemporary UI patterns are.
This reframed how I thought about my interactive Morse keyboard tool. I'd originally built it as a novelty — tap keys, see them convert to text. But once I understood the accessibility use case, I realized the actual design requirement wasn't "make tapping feel fun," it was "make the short/long distinction as forgiving and unambiguous as possible," which is a very different UX problem.
*Timing thresholds are the entire interface
*
With a full keyboard, a keypress is a keypress — there's no ambiguity about what the user meant. With binary tap input, the only signal is duration, which means your threshold for "this was a dot" vs. "this was a dash" is doing all the interpretive work a normal UI would split across dozens of distinct controls.
Get that threshold wrong and the interface becomes unusable, not just annoying. Too strict, and a user with slightly inconsistent motor control can't reliably produce a "short" input at all. Too loose, and dots and dashes blur into each other and nothing decodes correctly.
I ended up making the threshold adaptive rather than fixed — calibrating against the user's own first few inputs rather than assuming a universal duration cutoff, similar to the relative-classification approach I used for decoding recorded audio. The lesson generalized surprisingly well: anywhere you're classifying a single continuous signal into discrete categories, calibrating against the user's own behavior beats a fixed global threshold, whether that's tap duration, audio pulse length, or honestly any other analog-to-discrete UI decision.
*Why full-speed pattern recognition matters more than lookup tables
*
The other thing that changed my thinking: for someone using Morse as their primary communication method rather than a hobby, the difference between "slowly counting dots and dashes" and "recognizing a whole letter's rhythm instantly" isn't a nice-to-have — it's the difference between usable and unusably slow.
This is basically the same principle behind the Koch method in Morse code education (learn characters at full target speed from day one, and shrink the gaps between them over time, rather than starting slow and speeding up) — I built a practice tool around this for general learners, but the underlying idea applies directly to accessibility interfaces too: optimizing for eventual fluency matters more than optimizing for an easy first impression, if the tool is going to be used daily rather than once.
*The general lesson
*
None of this is really specific to Morse code. It's a broader point about designing for constrained input: the fewer degrees of freedom your user has, the more interpretive weight falls on your timing/classification logic, and the more that logic needs to adapt to the individual rather than assuming a fixed global standard. A keyboard shortcut system can afford to be rigid because keys are unambiguous. A single-switch binary system can't — the "interface" is really just your classifier, and it has to bend toward the user instead of the other way around.
It's a good reminder that accessibility constraints often aren't edge cases to bolt on afterward — they're frequently just the general design problem, minus the padding that makes it easy to ignore.
Top comments (0)