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 disability flies into a wall.
rootedbox
Keyboard accessibility is one of those things that tends to get swept under the rug or forgotten about entirely alongside accessibility in general. The funny thing is that the former usually falls out of the latter.
Part of the blame lands on the shoulders of popular UI frameworks (or in the case of those choosing to eschew use of such, the developers who made that choice). The older frameworks tend to make this fairly easy; for example, in Cocoa/AppKit (Mac native UI framework), one can pretty easily wire up their entire UI for proper keyboard navigation entirely visually (mostly just consists of connecting nextKeyView outlet between controls to produce a logical chain to tab-focus through). Defining key shortcuts is also simple; add a menu item for a command and set its corresponding shortcut (which in turn allows the user to rebind the shortcut in System Settings at will).
That sort of design has fallen out of favor with newer frameworks, unfortunately. The new preferred style seems to be a wireframe that the dev chooses which parts fill in, and often only the barest of essentials makes the cut.
cosmic_cheese
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 shortcuts) and setting a sensible tab order was super easy and straightforward.
Nowadays more than half of all software is made using non-native GUI toolkits (or sometimes no toolkits at all) that refuse to implement any of the typical keyboard navigation that would previously have come for free.
The keyboard makes computers a joy to use for me. Seeing it disappear makes me very sad. Seeing how the vast majority of people don't care that it disappeared makes me feel like an alien from another planet.
Timwi
My first experience with a GUI was the HP-40G calculators. By their nature, they only have arrows and accept/cancel buttons.
It featured very advanced symbolic computation features (CAS that would step you through intermediary results), but the magical thing was how equations, rather than being a series of characters, that you piece up into meaningful chunks through parentheses, where actually displayed like mathematicians would write them.
Then, to select and edit a specific part of the equation, you have a natural 'box'; numerator/denominator, etc, then you can drill down into the recusirve structure of the mathematical expression. It also means that regular edits are 'correct' by default: delete a parenthesis and your expression is syntactically invalid, whereas "replace the numerator f(x)^2 by 6a" keep you in the space of syntactically valid expressions.
In other words, this is the holy trinity of UI: semantic - accessible - efficient
The experience is unparalleled to this day, although writing it down I realize more why it was never really reproduced.
For a browser, I would imagine having blocks like:
A. meta (browser itself) / B. page (DOM)
A1. page controls (bookmark, ...) / A2. Navigation experience (font size, dark mode, ...)
One can dream :-)
woolion
I haven't seen this mentioned, but... let's talk for a moment about testing automation, and what pain it is to test GUI programs that are mouse-first... It is coincidental, but, in reality, it's pretty much a given, that a program that can be controlled through keyboard will be a lot easier to automate (not only for testing) because of the choice.
A typical way of doing things in a GUI program is to handle "events". The framework arranges for event delivery. The event has properties s.a. what UI element registered it and the sort of mouse action performed, and the handler code specializes on that combination to take the (hopefully) intended action.
When it comes to testing, in order to emulate such events, one would have to calculate the location of the element that "registered" the desired event in order to trigger the desired functionality. This is usually very hard to do because elements change their positions on screen, it can depend on screen resolution, display style of scrollbars and so on.
Another problem with the event-driven model is that it's typically asynchronous. The automation code has no good way of telling when the action associated with the even should take place, or, rather, when it should finish taking place, to assess the results.
Typically, programs controlled through keyboard expose functions associated with desired functionality (because they need to bind something to the key). The test automation then can call these functions instead of emulating events. The detection of the moment when the action finished execution thus becomes trivial.
crabbone
Power user experience is not the same thing as user experience in general. If you want to make the argument that all developer tooling should be keyboard-driven, fine, be my guest. But most people aren't willing to deal with the learning curve of keyboard-driven GUIs, and that's okay. We shouldn't force it.
HN's insistence on acting like all users are Arch Linux efficiency perfectionist hacker types is painfully corny.
(This reads harsher than I intended. Sorry about that. I love Arch Linux people. It's just think it's no less noble to serve the average Joe than to create the perfect tool for power users.)
manlymuppet
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 are a fundamental mismatch with keyboards. A keyboard driven UI shouldn’t have buttons.
The issue is that genuinely keyboard driven UIs like CLI or TUI suffer terrible discoverability that being the reason that mouse driven UI exists in the first place. So can we have a keyboard-driven UI that is as intuitive as clicking with a mouse?
YmiYugy
I agree but I think being usable by the keyboard isn't enough, because the shortcuts are often hard to discover and remember. I think the ideal is - like good TUIs - GUIs should put obvious hints on screen how to navigate via keyboard.
It would be really great to have some GUI frameworks for the common platforms (including web!) designed to do this and have some opinions on common shortcuts for common actions so we can standardize on something.
marklar423
I think the main reason people prefer TUI are certain assumptions that come with it. Like I assume a TUI runs on vim like shortcuts, allowing me to move with hjkl. It isn't the case everywhere, but it's what I have observed mostly.
When a software is created for the terminal, it can expect the users to know these certain shortcuts. But this cannot be assured for GUI.
stevesajeev
ALT+TAB, TAB, ↓, ↓, ↓, CTRL+HOME.
For a lot of people this is a recognizable pattern. Switch window, select element, scroll down, then snap back to the very top. The keyboard commands above should do the same thing no matter if it's your text editor or your web browser. People should know these are going to work regardless of what they're using. Because these aren't key commands going to the program, these are key commands going to the operating system. The program shouldn't be able to arbitrarily choose whether it abides by these. Consistency is important not only for speed, but for human understanding and capability. If every door had a different way of opening it such as drawing a series of lines or tapping a certain rhythm or belching thirty feet away people would be mentally taxed discovering that particular door's interfacing method, and common tools would not be able to help those who couldn't find the interface or use it because of disability or differing ability. It's only doors with extremely specialized designs like blast doors that have an unusual interface and interfacing method, because they're designed to do one very specific thing that lies far outside of common use cases. Your chatroom program, image viewer, or archive unpacker is not a blast door. Put a door handle on it where everyone expects it to be.
comments (10)
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 disability flies into a wall.
rootedbox
Part of the blame lands on the shoulders of popular UI frameworks (or in the case of those choosing to eschew use of such, the developers who made that choice). The older frameworks tend to make this fairly easy; for example, in Cocoa/AppKit (Mac native UI framework), one can pretty easily wire up their entire UI for proper keyboard navigation entirely visually (mostly just consists of connecting nextKeyView outlet between controls to produce a logical chain to tab-focus through). Defining key shortcuts is also simple; add a menu item for a command and set its corresponding shortcut (which in turn allows the user to rebind the shortcut in System Settings at will).
That sort of design has fallen out of favor with newer frameworks, unfortunately. The new preferred style seems to be a wireframe that the dev chooses which parts fill in, and often only the barest of essentials makes the cut.
cosmic_cheese
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 shortcuts) and setting a sensible tab order was super easy and straightforward.
Nowadays more than half of all software is made using non-native GUI toolkits (or sometimes no toolkits at all) that refuse to implement any of the typical keyboard navigation that would previously have come for free.
The keyboard makes computers a joy to use for me. Seeing it disappear makes me very sad. Seeing how the vast majority of people don't care that it disappeared makes me feel like an alien from another planet.
Timwi
The experience is unparalleled to this day, although writing it down I realize more why it was never really reproduced. For a browser, I would imagine having blocks like:
A. meta (browser itself) / B. page (DOM) A1. page controls (bookmark, ...) / A2. Navigation experience (font size, dark mode, ...)
One can dream :-)
woolion
A typical way of doing things in a GUI program is to handle "events". The framework arranges for event delivery. The event has properties s.a. what UI element registered it and the sort of mouse action performed, and the handler code specializes on that combination to take the (hopefully) intended action.
When it comes to testing, in order to emulate such events, one would have to calculate the location of the element that "registered" the desired event in order to trigger the desired functionality. This is usually very hard to do because elements change their positions on screen, it can depend on screen resolution, display style of scrollbars and so on.
Another problem with the event-driven model is that it's typically asynchronous. The automation code has no good way of telling when the action associated with the even should take place, or, rather, when it should finish taking place, to assess the results.
Typically, programs controlled through keyboard expose functions associated with desired functionality (because they need to bind something to the key). The test automation then can call these functions instead of emulating events. The detection of the moment when the action finished execution thus becomes trivial.
crabbone
HN's insistence on acting like all users are Arch Linux efficiency perfectionist hacker types is painfully corny.
(This reads harsher than I intended. Sorry about that. I love Arch Linux people. It's just think it's no less noble to serve the average Joe than to create the perfect tool for power users.)
manlymuppet
YmiYugy
It would be really great to have some GUI frameworks for the common platforms (including web!) designed to do this and have some opinions on common shortcuts for common actions so we can standardize on something.
marklar423
When a software is created for the terminal, it can expect the users to know these certain shortcuts. But this cannot be assured for GUI.
stevesajeev
For a lot of people this is a recognizable pattern. Switch window, select element, scroll down, then snap back to the very top. The keyboard commands above should do the same thing no matter if it's your text editor or your web browser. People should know these are going to work regardless of what they're using. Because these aren't key commands going to the program, these are key commands going to the operating system. The program shouldn't be able to arbitrarily choose whether it abides by these. Consistency is important not only for speed, but for human understanding and capability. If every door had a different way of opening it such as drawing a series of lines or tapping a certain rhythm or belching thirty feet away people would be mentally taxed discovering that particular door's interfacing method, and common tools would not be able to help those who couldn't find the interface or use it because of disability or differing ability. It's only doors with extremely specialized designs like blast doors that have an unusual interface and interfacing method, because they're designed to do one very specific thing that lies far outside of common use cases. Your chatroom program, image viewer, or archive unpacker is not a blast door. Put a door handle on it where everyone expects it to be.
Tanoc