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.
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
As a system macOS definitely has some holes in keyboard navigation, as well as a couple corners which are KB-navigable but the way to focus them is not immediately obvious.
On the app level, keyboard navigability depends on the developer. If they take the time to dot their I's and cross their T's it's between decent and great, but if they don't care it'll be bad.
MacOS has intentional holes in keyboard support. You have to go into settings and turn on a config for keyboard navigation to reach all elements. Apple intends for most users to navigate with a mouse.
There's no option to bring up a context menu with the keyboard. And there are no keyboard accelerators _AT_ _ALL_. Windows will underline the shortcut characters when you hold "alt".
> There's no option to bring up a context menu with the keyboard.
That used to be the case but has changed. Since at least macOS 15 the context menu key on typical keyboards is recognized and functions, and on other keyboards it can be opened with Ctrl+Return.
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.
> In fact, many GUI framework application guidelines explicitly encourage GUI application developers
Instead they should be engineered in a way that allows users to bypass those developers in a (at least) framework-consistent way as there will never be a time when they collectively become "keyboard-wise".
Mildly off topic, but getting to the original GUI vs TUI debate: Speed can also be a factor. I've yet to find a GUI file manager that is better than Midnight Commander/Far. I think there are some graphical orthodox file managers, but I could never do things as quickly in them as I could in mc.
So sure, add keyboard support to the GUIs. That's always a good thing. Just make sure they're also as responsive as in a TUI. Dialogs should appear instantly, etc.
The other headaches I've had with GUIs (in Linux) is the appearance can change if an underlying library changes. Even if I haven't upgraded the SW, if I upgrade one of the toolkits it relies on the app's appearance and behavior can change.
Three levels of GUI workflow operation: touchpad < mouse < keyboard. This is the main reason people fall in love with programs like vim: with enough experience it allows one to completely eliminate interface friction.
Agreed, but what "prevents" it is that making a good keyboard-driven UI takes a lot of taste, extra effort to build it, and it must be revisited any time the UI changes. It's duplicated work.
Ideally all GUIs/TUIs are usable with keyboard and mouse independently.
A good example of this is when you have a fancy keyboard-driven workflow yet you can't even do the most trivial task without placing two hands on your keyboard. Sometimes I just want to reach over and do it with one hand on the trackpad.
Where possible, there should be keyboard shortcuts/navigation.
Where appropriate, the labeling of fields and so forth should be such that it will work for a screen reader.
Often, the expedient option is to use an HTML front-end so that one can off-load most of that to the user's selection of web-browser (and where possible, things should be engineered so that Lynx is a valid option).
That said, I use OneNote and Macromedia Freehand and so forth w/ a stylus --- horses for courses.
It is excellent when I can do common tasks in an application without taking my hands off the keyboard. Especially utility apps like a calculator or password manager that I usually just need for a few seconds.
Bitwarden used to be keyboard friendly, but recent updates have removed those functions for reasons I can’t understand.
I have seen more GUIs these days that don't support even the bare minimum of using tab to cycle through various fields and selector buttons. Which as I recall was introduced in like windows 3.0.
I think we should also be finding ways to make things keyboard-driven that currently require a mouse. My side project is a keyboard centric flowchart editor which tries to merge the two between something typically 2D with pixel coordinates (normal flowchart software) and fitting it into a grid that has discrete coords so you can navigate with arrow keys.
I've been on this kick for a long time. A few years ago I was exploring a UI design tool that was entirely keyboard-driven, using pneumonic keychords inspired by Vim: https://github.com/danielvaughn/stride
My experience is that while it's awesome to have really deep keyboard-driven experience, it can't _only_ be that. You need some graphical controls to help guide users.
On the web, keyboard accessible web UIs are a WCAG 2.1.1 level A requirement - that's literally the most basic level of accessibility standard (unless you count 'failed' as a level). If your website / web app isn't achieving that then you haven't tried very hard.
Keyboard driven, and keyboard accessible are not the same thing.
I’ve made a web application at work able to be keyboard driven one time and exactly 0 users out of thousands made use of it. People just don’t want to pay the upfront cost. In the old TUI days it was the only way to use something so you had no choice.
To be completely keyboard inaccessible I’d argue that you almost have to try and achieve it.
The one UI invention many web UIs now add is the universal command search bar. I’m most familiar from it from Jetbrains IDEs where it’s been for over a decade and it is a remarkable upgrade on browsing menus. With the KeyPromoter extension on I even learned the keyboard shortcut over time. Good UI pattern and now this universal command search is everywhere: Cloudflare, Mercury, etc.
Similarly, under macOS in most apps ⌘⇧/ opens a full menubar search which can surface most app functionality from the keyboard. Not quite as good as a command palette but close, and devs don't need to do anything to opt in except populate the app's menus properly.
Well TIL. Great tip. I only ever hit that key combination when I look around Finder and find myself unable to go up one level easily from the icon bar - an action I do constantly.
People gave the ribbon interface a lot of shit but one thing they definitely got right was making absolutely every option reachable from some keyboard shortcut. Some of the shortcuts get a little long but you can just but those as a hotkey if you use them a lot.
I agree 100%. The mouse is great and I don't think GUIs should drop it or anything, but it's wonderful to have the ability to keep your hands on your keyboard when doing data entry tasks and the like. I also think that when you design for both keyboard and mouse input, it will force you to consider rough edges of your UI design in a way that you wouldn't have to if you were just designing for one. So the app will be better as a result.
> We just need better, efficient and faster GUIs to put these TUIs to an end.
Well, yeah, it just that those GUIs failed to appear for at least 30 years.
> It is time to move on from using this arcane technology from the 60s-70s.
You mean the GUIs? They were being in development since the early 70s, you know, but they really have flourished in the 80s. So, it's already a 40-years-old paradigm that still haven't managed to displace another contemporary paradigm of TUIs. Well, who knows, maybe in 40 more years it'll make it.
Yes and no. The big advantage of a GUI is having interactive 2D coordinate input support (aka a pointer, or gestures.) While I think a keyboard can be a great control surface, that’s one thing it really lacks and only GUIs really offer. So to enforce that the whole GUI must be keyboard-drivable requires limiting the major advantage of the GUI. I’m a fan of the Emacs or Plan9 styles where the keyboard and pointer are able to be used together synergistically. You also see some of this in tools like video, DAW, and 2D/3D graphical scene editors.
Yikes, no! One of the reasons old timers like me say that using a computer has sucked a lot in the last ~20 years is the use of a browser as an interface to everything.
If you want to make an app that needs a browser to use, then please drastically improve the browser's interface. I mean, this is a no brainer. TUIs are way more superior to doing things via Safari/Firefox/Chrome.
Hard disagree. Most web interfaces are worse than most native UIs. Inconsistent rendering, keyboard shortcuts and navigation between apps, slow response times, and more.
There's a reason everyone who knows what Electron is bashes every "native" app built with Electron.
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.
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
As a system macOS definitely has some holes in keyboard navigation, as well as a couple corners which are KB-navigable but the way to focus them is not immediately obvious.
On the app level, keyboard navigability depends on the developer. If they take the time to dot their I's and cross their T's it's between decent and great, but if they don't care it'll be bad.
MacOS has intentional holes in keyboard support. You have to go into settings and turn on a config for keyboard navigation to reach all elements. Apple intends for most users to navigate with a mouse.
It’s in the accessibility settings.
https://support.apple.com/en-za/guide/mac-help/mchlc06d1059/...
"Some holes"? That's an understatement.
There's no option to bring up a context menu with the keyboard. And there are no keyboard accelerators _AT_ _ALL_. Windows will underline the shortcut characters when you hold "alt".
> There's no option to bring up a context menu with the keyboard.
That used to be the case but has changed. Since at least macOS 15 the context menu key on typical keyboards is recognized and functions, and on other keyboards it can be opened with Ctrl+Return.
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.
> In fact, many GUI framework application guidelines explicitly encourage GUI application developers
Instead they should be engineered in a way that allows users to bypass those developers in a (at least) framework-consistent way as there will never be a time when they collectively become "keyboard-wise".
Mildly off topic, but getting to the original GUI vs TUI debate: Speed can also be a factor. I've yet to find a GUI file manager that is better than Midnight Commander/Far. I think there are some graphical orthodox file managers, but I could never do things as quickly in them as I could in mc.
So sure, add keyboard support to the GUIs. That's always a good thing. Just make sure they're also as responsive as in a TUI. Dialogs should appear instantly, etc.
The other headaches I've had with GUIs (in Linux) is the appearance can change if an underlying library changes. Even if I haven't upgraded the SW, if I upgrade one of the toolkits it relies on the app's appearance and behavior can change.
Somehow this is never an issue with TUIs.
Three levels of GUI workflow operation: touchpad < mouse < keyboard. This is the main reason people fall in love with programs like vim: with enough experience it allows one to completely eliminate interface friction.
Agreed, but what "prevents" it is that making a good keyboard-driven UI takes a lot of taste, extra effort to build it, and it must be revisited any time the UI changes. It's duplicated work.
Ideally all GUIs/TUIs are usable with keyboard and mouse independently.
A good example of this is when you have a fancy keyboard-driven workflow yet you can't even do the most trivial task without placing two hands on your keyboard. Sometimes I just want to reach over and do it with one hand on the trackpad.
> extra effort to build it
Also extra effort to use it. This is why we have the “how do I exit vim?” meme.
A good user interface needs escape hatches so users can keep their head above water while they learn to swim.
Most of what people want when they say keyboard-driven is closer to a cockpit (requires expert knowledge) than a general purpose UI.
Where possible, there should be keyboard shortcuts/navigation.
Where appropriate, the labeling of fields and so forth should be such that it will work for a screen reader.
Often, the expedient option is to use an HTML front-end so that one can off-load most of that to the user's selection of web-browser (and where possible, things should be engineered so that Lynx is a valid option).
That said, I use OneNote and Macromedia Freehand and so forth w/ a stylus --- horses for courses.
It is excellent when I can do common tasks in an application without taking my hands off the keyboard. Especially utility apps like a calculator or password manager that I usually just need for a few seconds.
Bitwarden used to be keyboard friendly, but recent updates have removed those functions for reasons I can’t understand.
I have seen more GUIs these days that don't support even the bare minimum of using tab to cycle through various fields and selector buttons. Which as I recall was introduced in like windows 3.0.
Or page up/down.
I think we should also be finding ways to make things keyboard-driven that currently require a mouse. My side project is a keyboard centric flowchart editor which tries to merge the two between something typically 2D with pixel coordinates (normal flowchart software) and fitting it into a grid that has discrete coords so you can navigate with arrow keys.
I've been on this kick for a long time. A few years ago I was exploring a UI design tool that was entirely keyboard-driven, using pneumonic keychords inspired by Vim: https://github.com/danielvaughn/stride
My experience is that while it's awesome to have really deep keyboard-driven experience, it can't _only_ be that. You need some graphical controls to help guide users.
Ideally you should have both. Every action should be doable by mouse only and by keyboard only. That way you can cater to all kinds of users.
On the web, keyboard accessible web UIs are a WCAG 2.1.1 level A requirement - that's literally the most basic level of accessibility standard (unless you count 'failed' as a level). If your website / web app isn't achieving that then you haven't tried very hard.
Keyboard driven, and keyboard accessible are not the same thing.
I’ve made a web application at work able to be keyboard driven one time and exactly 0 users out of thousands made use of it. People just don’t want to pay the upfront cost. In the old TUI days it was the only way to use something so you had no choice.
To be completely keyboard inaccessible I’d argue that you almost have to try and achieve it.
The one UI invention many web UIs now add is the universal command search bar. I’m most familiar from it from Jetbrains IDEs where it’s been for over a decade and it is a remarkable upgrade on browsing menus. With the KeyPromoter extension on I even learned the keyboard shortcut over time. Good UI pattern and now this universal command search is everywhere: Cloudflare, Mercury, etc.
Love it.
Similarly, under macOS in most apps ⌘⇧/ opens a full menubar search which can surface most app functionality from the keyboard. Not quite as good as a command palette but close, and devs don't need to do anything to opt in except populate the app's menus properly.
Well TIL. Great tip. I only ever hit that key combination when I look around Finder and find myself unable to go up one level easily from the icon bar - an action I do constantly.
But it is really hard to remember the shortcuts
People gave the ribbon interface a lot of shit but one thing they definitely got right was making absolutely every option reachable from some keyboard shortcut. Some of the shortcuts get a little long but you can just but those as a hotkey if you use them a lot.
I agree 100%. The mouse is great and I don't think GUIs should drop it or anything, but it's wonderful to have the ability to keep your hands on your keyboard when doing data entry tasks and the like. I also think that when you design for both keyboard and mouse input, it will force you to consider rough edges of your UI design in a way that you wouldn't have to if you were just designing for one. So the app will be better as a result.
Spin up a Windows 3.11 and later instance to try this out.
Why, are we speed running the de-evolution of UI?
Because not everyone has a mouse or is able to use a mouse. Accessibility matters.
Not everyone has a (non-screen) keyboard either, you know.
Right, so we should have both options.
yes please ! even AI would appreciate this !
I'm glad the fad of TUIs are dying, I don't get the hype of them.
We just need better, efficient and faster GUIs to put these TUIs to an end.
Take a look at gpgui and glaze leading on this. There should be no reason to use TUIs anymore.
It is time to move on from using this arcane technology from the 60s-70s.
https://gpui.rs/
https://glaze.app/
> We just need better, efficient and faster GUIs to put these TUIs to an end.
I think, firstly, we need less meaningless red-tape shenanigans from MS/Apple to publish GUI apps
> gpui.rs
I clicked. Never trust a gui library without screenshots.
I'll never quit building TUIs, though. I'm building more TUIs now than ever, with AI assistance making it easy.
> We just need better, efficient and faster GUIs to put these TUIs to an end.
Well, yeah, it just that those GUIs failed to appear for at least 30 years.
> It is time to move on from using this arcane technology from the 60s-70s.
You mean the GUIs? They were being in development since the early 70s, you know, but they really have flourished in the 80s. So, it's already a 40-years-old paradigm that still haven't managed to displace another contemporary paradigm of TUIs. Well, who knows, maybe in 40 more years it'll make it.
Yes and no. The big advantage of a GUI is having interactive 2D coordinate input support (aka a pointer, or gestures.) While I think a keyboard can be a great control surface, that’s one thing it really lacks and only GUIs really offer. So to enforce that the whole GUI must be keyboard-drivable requires limiting the major advantage of the GUI. I’m a fan of the Emacs or Plan9 styles where the keyboard and pointer are able to be used together synergistically. You also see some of this in tools like video, DAW, and 2D/3D graphical scene editors.
What's specifically is the limitation?
ain't no way my mom is learning vim
Read the article. The argument is not "GUId should require keyboard navigation", it's "everything should be possible with the keyboard".
TUIs are an abomination and most GUIs should just be web.
CLIs should be preferred when available. Learning them pays you back when it's time to write a script or pipe massive amounts of data.
> and most GUIs should just be web.
Yikes, no! One of the reasons old timers like me say that using a computer has sucked a lot in the last ~20 years is the use of a browser as an interface to everything.
If you want to make an app that needs a browser to use, then please drastically improve the browser's interface. I mean, this is a no brainer. TUIs are way more superior to doing things via Safari/Firefox/Chrome.
> most GUIs should just be web.
Hard disagree. Most web interfaces are worse than most native UIs. Inconsistent rendering, keyboard shortcuts and navigation between apps, slow response times, and more.
There's a reason everyone who knows what Electron is bashes every "native" app built with Electron.
yeah--the reason is the bloat and overhead electron brings.
nobody cares about the web layer