Live data from Hacker News

GUIs should be fully keyboard-driven

ckardaris.com

261–270 of 510 posts

Re: GUIs should be fully keyboard-driven

#261
post #238

Earlier quoted context omitted.

Using AI to close gaps in accessibility is like adding treads to your vehicle because society is too lazy to pave roads.

I think people outside of enterprise have no idea the cost to audit and fix a massive website. The law is a forcing function here. Lawsuits can and do happen when sites of a certain size fail to implement government-mandated laws. This is a good thing, IMO, but it only comes into force in the largest cases. If there is a credible path to 1/10th the cost (while still providing liability insurance which is a critical p…

I'm not outside of enterprise and have worked hands-on for over a decade with AI-driven customer workflows. The cost of accessibility audits are NOT higher than AI R&D or third-party B2B contracts for vaporware touting to do the same.

Sorry if that assertion stands opposed to your value prop.

Re: GUIs should be fully keyboard-driven

#262

I work on ADA a lot for my company. Please put on some headphones, turn on the voice assistant of your OS, put on some blinders, and run your app or website… no mouse, just keyboard. 1. Democracy is about access; make sure everyone has access to your software. 2. The keyboard allows folks with disabilities and power users to fly through your website/app… that being said… the second a tab is off, the person with a dis…

I worked on Microsoft’s Windows QA team long ago. My team used to have “No-mouse Tuesdays”: you were supposed to do all your normal work but only using the keyboard.

Re: GUIs should be fully keyboard-driven

#263
post #88

What does it mean though for a GUI to be keyboard-driven? The obvious way is that every action simply gets a shortcut assigned. My counter would be that that is not really keyboard-driven, but merely keyboard-compatible.There is the issue of discoverability. The best practice right now seems to display the shortcuts of buttons in tooltips, menu items, or when pressing a different shortcut. I’d content that buttons ar…

start with CUA standard.

Its only been around for 50 years, but few people ever consider it.

Re: GUIs should be fully keyboard-driven

#264

Earlier quoted context omitted.

Where this falls apart is commercial software. The issue is we use off-the-shelf frameworks and tools for commercial software. And then we don't train developers on how to write high-volume software. Commercial software is THE power user use case. Your users will be using your software 8 hours a day, 5 days a week, for years. And still, the software is obtuse point-and-click garbage. Meanwhile commercial software fro…

I think you vaaastly overestimate how excel is used by most users if anything, excel exceeds in being MOUSE-driven - it's intuitive in what you press and what you drag and that's kinda my problem with the TFA - author is not representative of typical user. Mouse interaction is the king

Screwing with a keyboard combo in Excel... like Shift-Space to highlight a row... is like an IDE deciding to swap the key-bindings for '{' and '['. You'd have entire accounting and marketing departments in rebellion.

Devs consistently underestimate how many power users of Excel there are, and often don't understand how they operate.

Re: GUIs should be fully keyboard-driven

#265

Earlier quoted context omitted.

you are arguing against a strawman. Most reasonable people want support for both keyboard and mouse-based navigation. For example, why did Edge and possible chrome, remove support for Back via the backspace key? Literally, why remove something that exists and that some people might use? Same with some web forms where hitting enter in a text box does nothing. I expect it to submit a form, but very often, it does nothi…

> For example, why did Edge and possible chrome, remove support for Back via the backspace key? Because people were triggering it by accident all the time. Firefox and Safari don't navigate back on backspace either. Enter only auto-submits if there's a visible submit button or if there's just one input, and that behavior goes back as far as I can remember.

Yeah, that wasn't an attempt to remove keyboard navigation, that was fixing a painful error in keyboard navigation.

Re: GUIs should be fully keyboard-driven

#266
For people who want to navigate browsers only with the keyboard, I recommend vimium https://vimium.github.io/

It's a plugin that enables many keyboard shortcuts, so that you almost don't need to touch the mouse to navigate.

For me, it's such a productivity booster, especially the ability to navigate links without pointing at them to click

Re: GUIs should be fully keyboard-driven

#267

I'll go one step further: anything you can do in a GUI should also be possible to do through a CLI and yes, also with code libraries. If webapps have n-tier architectures, then so should GUI software. (we can lie and say that this is to support AI, in actuality it's to have proper programmatic automation and support for custom interfaces instead of GUI apps being black boxes)

I agree but how does this work with stateful apps

Re: GUIs should be fully keyboard-driven

#269

I work on ADA a lot for my company. Please put on some headphones, turn on the voice assistant of your OS, put on some blinders, and run your app or website… no mouse, just keyboard. 1. Democracy is about access; make sure everyone has access to your software. 2. The keyboard allows folks with disabilities and power users to fly through your website/app… that being said… the second a tab is off, the person with a dis…

I worked on Microsoft’s Windows QA team long ago. My team used to have “No-mouse Tuesdays”: you were supposed to do all your normal work but only using the keyboard.

What I wouldn't give to work for a company that actually cares about QA.

Re: GUIs should be fully keyboard-driven

#270
In the latest app my company is working on, we deliberately wanted to support usage over SSH.

We basically designed the app as a TUI, but implemented mouse events so you can also drive it like a GUI.

When we hit the limits of the terminal (couldn’t register the app as a DWM window and throw up separate windowed modals etc) we forked and extended ghosttty.

Now it also supports mouse hover events, DWM popups, and a bunch of other good stuff. We plan to add icons next.

Post reply on HN