> I have never been convinced by this argument. The aggregate number sounds fantastic but I don't believe that any meaningful work can be done by each user saving 1 second. That 1 second (and more) can simply be taken by me trying to stretch my body out.
I’d see this differently from a user perspective. If the average operations takes one second less, I’d spend a lot of time less waiting for my computer. I’d also have less idle moments where my mind wanders while waiting for some operation to complete too.
Audiobook are mouth speed but have no pause. When reading slowly, I often want to pause a few seconds and think about what I just read before moving on to the next sentence.
I pause audiobooks all the time by squeezing the base of my earbud, or pressing the big pause button on my Bluetooth speaker. Works great. As well as the triple-tap to go back 15 seconds to hear something again.
Readers of HN will value flexibility and extensibility, but the other 99% of the folks there are fine with totally locked-down devices because it’s the only thing they know of. The lack of extensibility likely doesn’t affect sales/profit in any significant proportion.
TUI tools are generally as accessible as the terminal on which they run.
GUI apps are much trickier. They require that the developer implement integration with accessibility frameworks (which vary depending on X11/Wayland) or use a toolkit which does this.
GUI kits like AppKit or GTK have built-in accessibility features like standard components (input fields, dropdown boxes) and view hierarchy that interact with accessibility tools for free. It's the main upside of a GUI.
TUIs are tricky.
I think TUI accessibility generally involves rereading the screen on changes (going by macOS VoiceOver). It can optimize this if you use the terminal cursor (move it with ansi sequences) or use simple line-based output, but pretty much zero TUIs do this. You'd have to put a lot of thought into making your TUI screenreader friendly compared to a GUI.
The thing going for you when you build a TUI is that people are used to bad accessibility so they don't expect you to solve the ecosystem. Kind of like how international keyboards don't work in terminal apps because terminal emulator doesn't send raw key scans.
How are TUI tools just as accessible as the terminal? Take a visually-simple program like neomutt or vim. How does a vision-impaired user understand the TUI's layout? E.g. splits and statusbar in vim, or the q:Quit d:Del... labels at the top of neomutt. It seems to me like the TUI, because it only provides the abstraction of raw glyphs, any accessibility is built on hopes and dreams. More complicated TUIs like htop or glances seem like they would be utterly hopeless.
When it comes to GUIs, you have a higher level of abstraction than grid-of-glyphs. By using a GUI toolkit with these abstractions, you can get accessibility (relatively) for free.
I’ve been writing my own flashcards (purely text-based, no SQLite like in this case) primarily because Anki never worked out for me (too hard to use, too hard to sync, everything too complicated). I have zero time or motivation to research how to import data from it.
This needs to be contributed by folks coming from Anki. By folks who actually have interest in the feature.
I’d see this differently from a user perspective. If the average operations takes one second less, I’d spend a lot of time less waiting for my computer. I’d also have less idle moments where my mind wanders while waiting for some operation to complete too.
reply