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

301–310 of 513 posts

Re: GUIs should be fully keyboard-driven

#301

Post by bonestamp2 »

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…

> the second a tab is off

Can you explain what you mean by this phrase?

Re: GUIs should be fully keyboard-driven

#302

Post by jaggederest »

Velocifyer wrote: post #297
jaggederest wrote: post #255

Earlier quoted context omitted.

Some of the things we take for granted in UI/UX originated that way, like automatic hamburger menu hide/show (for very large zoom) and "scroll to content/top" buttons for screenreaders, which, if you've ever tried to read a recipe online are pretty critical. Captions on videos are also like that, although there you might share blame to them for enabling the poor sound mastering on things like, legendarily, Tenet, per…

What are the advantage of “scroll to content/top” buttons over for screen readers? I think that the use of those buttons is for when the CSS fails to load.

It's essentially the same thing, but a lot of the time people will add a sr-only button at the very top that just goes straight there, and one at the bottom if the screen reader gets stuck in the footer nav, as well. Depending on which screenreader people use they sometimes only work on the actual hydrated markup, so isn't always visible the way you'd expect. It's been a while since I did a11y tho so I'm probably hopelessly out of date.

Re: GUIs should be fully keyboard-driven

#304

Post by cpeterso »

BobbyTables2 wrote: post #281
cpeterso wrote: post #262

Earlier quoted context omitted.

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.

I assume MouseKeys was cheating ?

Send fair to me: someone’s got to test Mouse Keys! :)

Re: GUIs should be fully keyboard-driven

#305

Post by tptacek »

gblargg wrote: post #258
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…

That was my first thought, that a TUI is still a GUI. Close your eyes and explain how you can use a TUI from the keyboard. The only difference is what the display can render.

Modern GUI frameworks maintain a visual UI tree for on-screen interaction, and a semantic tree for accessibility features. You can find TUI libraries that do things like this, but for most TUIs, if you close your eyes and have the UI read to you, you're going to hear "dash dash dash dash dash dash bracket dash", because the fundamental concept of a TUI is in-band UI signalling.

For accessibility (the topic of this subthread), TUIs are not like GUIs.

Re: GUIs should be fully keyboard-driven

#306

Post by tptacek »

YmiYugy wrote: 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…

It's perfectly possible to design a GUI without button controls, where literally all the interaction is done with keyboard inputs. It's still not a TUI: it has graphical visual layout, and the UI signaling is out of band with respect to the data it's presenting.

Re: GUIs should be fully keyboard-driven

#307

Post by cosmic_cheese »

nashashmi wrote: post #285
pathartl wrote: post #15

Earlier quoted context omitted.

Funny that you bring macOS, because for _decades_ I've struggled with navigating it without a keyboard. Windows components however, especially old ones, are incredibly accessible

> Windows components however, especially old ones, are incredibly accessible Bing, Bing, Bing! I came here to vent how the new windows 10 and windows 11 interfaces (made by Mac enthusiasts, ughh) have omitted keyboard accessibility for a cleaner look. They also dropped drag and drop support (which I never knew about in windows 7) and I completely missed how useful it could be on Windows 10/11.

For whatever it's worth, the new W10/11 designs aren't in line with traditional Mac design philosophies either. They're more in line with those of iOS and Android with how they tend to bury and omit options entirely and prefer massive whitespace.

Re: GUIs should be fully keyboard-driven

#308

Post by gblargg »

tptacek wrote: post #305
gblargg wrote: post #258

Earlier quoted context omitted.

That was my first thought, that a TUI is still a GUI. Close your eyes and explain how you can use a TUI from the keyboard. The only difference is what the display can render.

Modern GUI frameworks maintain a visual UI tree for on-screen interaction, and a semantic tree for accessibility features. You can find TUI libraries that do things like this, but for most TUIs, if you close your eyes and have the UI read to you, you're going to hear "dash dash dash dash dash dash bracket dash", because the fundamental concept of a TUI is in-band UI signalling. For accessibility (the topic of this su…

I see, modern "GUI" programs aren't just GUI, whereas a TUI is just a GUI.

Re: GUIs should be fully keyboard-driven

#309

Post by robomartin »

rustystump wrote: post #296
robomartin wrote: post #280

Earlier quoted context omitted.

> 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…

Classics are still there, at least they were for me. Then again, i didnt have the pleasure of experiencing American public education. As much as i do agree, overtime language does eventually change but it can happen over our dead bodies

[dead]

Re: GUIs should be fully keyboard-driven

#310

Post by the_lucifer »

kerblang wrote: post #149
magicalhippo wrote: post #72

Earlier quoted context omitted.

Which, if you made say a regular Win32 application, was guaranteed. These newfangled frameworks dropped the ball, if anything.

Not guaranteed but easy, because Windows has mnemonics, where you can associate arbitrarily nested menus with actions, and each menu can have its own mnemonic key, so that you press ALT, then, say, "k", then, maybe "m" and so on, following along with the menus as they drop down. This way it becomes easy to memorize key sequences; start by navigating with arrow keys, then eventually speed up as you memorize each menu…

> Not guaranteed but easy, because Windows has mnemonics, where you can associate arbitrarily nested menus with actions, and each menu can have its own mnemonic key, so that you press ALT, then, say, "k", then, maybe "m" and so on, following along with the menus as they drop down.

> I'd even say friendlier than MacOS (heresy!!)

Honestly, I disagree. If you've used macOS for a length of time, you might be aware of the universal menu search system using (cmd+? i.e. cmd+shift+/). Hit that, type the menu item name, and simply hit return to activate it. Doesn't get simpler than that. The alt+ system always feels very janky to me on Windows because on many apps, hitting Alt relayouts the entire app sometimes to show the menu bar on top.

Post reply on HN