Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GUIs should be fully keyboard-driven

ckardaris.com

Post reply on HN
Print view View original

461–470 of 513 posts

Re: GUIs should be fully keyboard-driven

#461

Post by card_zero »

robomartin wrote: post #280
iLemming wrote: post #251

Earlier quoted context omitted.

Democracy is not about mob rule, it's about a dialog. Sure, sometimes it becomes heated argumentation and noise, but it's not so much about "ruling". Lincoln in his union address in 1860 said: "I so adopt it because it furnishes a precise and an agreed starting point for a discussion between Republicans and that wing of the Democracy headed by Senator Douglas." "Democratization" in a sense is about making things acce…

> Democracy is not about mob rule, it's about a dialog. No my friend, Democracy is majority rule, which easily turns into a ruling mob. It has nothing whatsoever to do with dialog. Also, your quote of Lincoln's address is taken completely out of context. He was talking about his opposition of the ideas of a faction of Democrats who were in favor of slavery and his support of the majority of Republicans who believed s…

Pantisocracy: rule by socks and panties.

Re: GUIs should be fully keyboard-driven

#462

Post by ranger_danger »

toast0 wrote: post #243
Telaneo wrote: post #232

Earlier quoted context omitted.

Fair. I just remember them being inconsistent between the English and localised versions of Windows, and given I used both, that turned into a nothing-feature. Another comment mentioned you could edit the underlines in Office 2003, but I never knew that back in the day (or until today for that matter...).

It's pretty hard for the shortcuts to be consistent and localized. Especially if you also use different keyboard layouts when you're using different languages... Even for keys that aren't mnemonic, do you want undo to be ctrl + z or ctrl + the key closest to left shift?

And for complex languages like CJK, often the key you would press is not even present in the string at all.

Example: What should the accelerator be, and how should it be displayed, if your "Exit" option is labeled 終了?

I checked VLC and apparently they use: 終了 (Q)

Even though "Q" doesn't necessarily make any sense to Japanese people who don't understand any English.

Re: GUIs should be fully keyboard-driven

#463

Post by unfamiliar »

Timwi wrote: post #383

It's so weird for me to live through software evolution to the point where this no longer goes without saying. In the Windows 3.1 days, it was nearly impossible to make a program that wasn't fully keyboard-usable. Even if you left out all the hotkeys in the menus and messed up the tab order, it was still possible (even if annoying) to get through it with the keyboard, and adding the hotkeys (as well as actual shortcu…

Same. I think part of the problem is that keyboard shortcuts are often not very discoverable. For example on Macos, pop-up dialogs often have keyboard shortcuts for their non-default buttons, but I'm not sure where you're supposed to learn this. Lack of discoverability leads to many people not using them which leads to devs not implementing them.

Re: GUIs should be fully keyboard-driven

#464

Post by jojobas »

rootedbox wrote: post #152

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 understand the sentiment, but there are limitations. You can't make a wheelchair-accessible treehouse, but that's not an argument against treehouses. Democracy is about letting people do whatever they want, the laws that forbid treehouse cafes aren't particularly democratic.

Re: GUIs should be fully keyboard-driven

#465

Post by jasonlotito »

Xirdus wrote: post #428
ckardaris wrote: post #357

Earlier quoted context omitted.

But you can — or should be able to — independently toggle all of those features. For example, the app should work in high-contrast mode with disabled color coding, it should work with touch gestures disabled, etc. A good common framework helps here. Then, it's up to each user to set their settings properly.

Riddle me this - why would you want to disable something that increases usability of an application? (Yes, this is a loaded question - I never said these features are bad, just that usability and accessibility are sometimes at odds with each other.)

> Riddle me this - why would you want to disable something that increases usability of an application?

Why don't you run your apps/OS with every usability feature enabled? Share your reasons.

Re: GUIs should be fully keyboard-driven

#466

Post by xg15 »

umpalumpaaa wrote: post #353
Xirdus wrote: post #339

Earlier quoted context omitted.

> accessibility is just usability. all it is is making sure your product is as usable by as many people as possible. Not always. There are things that increase usability for fully abled people but decrease it for disabled people. Color-coding is a common one. Another is using smaller font size to make more info visible at once, or advanced touch gestures that can be accidentally triggered by shaky hands. Then there a…

Colors should be an OS feature. On iOS and macOS you can remap colors globally and it works in all native apps. There are presets fire the common cases: red/green issues, color blindness etc and you can make your own. This has its limitations though eg if you are not able to distinguish at least 5 or so colors… any colors.

should be, but then you will upset all the marketing folks and their brandings.

Re: GUIs should be fully keyboard-driven

#468

Post by ethin »

gmueckl wrote: post #362
ethin wrote: post #123

Earlier quoted context omitted.

I know of at least 5 different UI frameworks in different languages which are partially accessible or completely inaccessible. Some include Dlangui, Tkinter (although this is getting better), DearImGui... Really any UI that decides to draw it's widgets by frame. QT also has some accessibility problems. In apps made with any of these, they are either impossible to use with assistive technology (and therefore the keybo…

Dlangui is so niche that I am amazed to even see it here. DearImGui is intended for thowing together some slap-dash UI widgets for debugging things like interactive rendering. Do Qt built-in widgets have huge problems? Inwould assume that custom widgets invariably do because approximately nobody writes any accessibility handling for them.

> Dlangui is so niche that I am amazed to even see it here.

Eh, I'm testing whether I can make it fully accessible, since I happen to like the D language itself. But the UI without my changes is entirely inaccessible.

> DearImGui is intended for thowing together some slap-dash UI widgets for debugging things like interactive rendering.

That's probably what it's intended for, but people use it for far more than that, which is a problem. Even if it weren't, it's inaccessibility is a problem.

> Do Qt built-in widgets have huge problems? Inwould assume that custom widgets invariably do because approximately nobody writes any accessibility handling for them.

Sometimes. Depends on the widget. I've had QLineEdit's crash apps when all-select-copy workflows have been used, or with NVDA on win32 you can't ordinarily read a multi-line QT QLineEdit or other multi-line input since the focus will remain on the first line, always. Webviews are entirely inaccessible at the moment.

Re: GUIs should be fully keyboard-driven

#470

Post by Zigurd »

rootedbox wrote: post #152

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…

Both Google and Apple have MCP-like interface frameworks for agents that developers can enable so their apps are not dependent on touch or vioce or keyboard or pointing device or D-pad interactions.

This is the correct way to do it because it puts the interaction responsibility into the agent, not the app. That enables the agent to work across multiple apps to achieve tasks by interacting with the user. That's where both sides of the interaction should live. That's where the context of the interaction exclusively lives because no individual app holds the full context. That also makes it the place where solving adaptive interface challenges is best implemented.

Post reply on HN