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.
Anyway, it's not even an option anymore, under the European Accessibility Act, government and (since last year) public services (websites, apps, appliances, etc) all need to be accessible; for websites this means implementing WCAG 2.something to level AA, which includes things like minimum contrast requirements, captioned videos, and increasing font size without losing information.
And it's often considered an afterthought because by and large, designers and developers are relatively young, 20-40 some year olds working on Macbooks with 4K displays. Some may be wearing glasses but broadly speaking that's the extent of their disabilities.
Have you some more stories of massive text, huge margins and padding helping UIX for healthy visitors?
accessibility work isn't just about making things possible for folks with disabilities, it's about making things better for everyone.
Which like, we're all eventually gonna be odd folk! That's what age does to us. But we should understand these accommodations as being a net positive, not a cost, to society.
In your situation, a couple possible solutions come to mind. 1) turn on "mouse keys" which lets you use the numpad to move the mouse and click, 2) a vim addon for the browser (e.g. vimperator or tridactyl) likely could've clicked the button via the hints mode. It's in the past now so maybe these wouldn't have worked or you didn't know, of course, just fun to think of what I would've done.
I'm someone who enjoys this kind of work, especially when the target is a stylized drop down - I got to spend a week with the MDN page for the ARIA combobox open, trudging through all of the ins and outs of keyboard accessibility and I know I'm still missing a couple things (typing when the control is focused but not open, for example), and having clearly defined specs is something we don't seem to get a lot in webdev
It doesn't scroll to the "useful" part of an article. It doesn't skip past the introduction / filler / two pages of "this is how my grandma used to make it." The only thing it does is getting you past the top navbar and such, and moving focus straight to the beginning of the article.
Landmarks are important, but to navigate by landmark, you need to be experienced enough to know the right quicknav keys. Some beginner users might not be.
- accessibility is just usability. all it is is making sure your product is as usable by as many people as possible.
- it's a myth that "people with disabilities" are some other that excludes you, and 'accessibility' or assistive technologies only benefits other people. Everyone is only temporarily 'abled'. You need to use prescription glasses to comfortable read a computer screen? You're a parent trying to watch some TV while getting your child to sleep? All benefit from assistive technologies.
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 are accessibility features that actively harm fully abled users, like sticky keys or screen readers that automatically follow focused UI elements.
A good common framework helps here. Then, it's up to each user to set their settings properly.
The idea that it must be more accessible because it’s confined to a mono space typeface and communicates state mostly by changing the foreground and background color of the text it renders makes no sense to me.
With a TUI or a web app, screen readers will always have some access, because no matter what you do, the text layer is always there. This may not be enough accessibility to use the app or to complete some specific workflow, but a screen reader user will at least have a rough idea of what's going on. For web apps, that's a good basis to start from once you finally realize that accessibility is something you need.
Desktop apps are much more of a mixed bag. Most frameworks draw their UI themselves, basically pixel by pixel, instead of using some text-based platform primitives. If your framework doesn't expose UI semantics to the OS, a screen reader user gets absolutely nothing, basically a blank window with no visible content or controls. If you're just a developer using that framework, it's a very difficult situation to get out of, once a11y becomes a business requirement.
GTK on anything but Linux is the major offender these days, so are many niche Rust frameworks and anything involving game or game-like UI. QT, Java Swing and Flash used to be this way historically.
That's not why. It's because TUI apps have to be designed around the strong possibility that a mouse isn't even available.
Also in a TUI you never ever have that issue that some text isn't copy/pastable like some dialogue boxes, in which case the screen reader might have issues picking it up too.
And in a TUI you don't have to deal with that window management crap. Moving stuff around because something else is on top. Everything happens within that little square.
How would I make this more accessible for the blind or people with bad vision?
2. Make sure that the text box has a label that says “search” or “filter” and not just a magnifying glass icon. You can only get away with an icon if the GUI toolkit allows you to give it an alt text.
3. Make sure that this label has a hotkey (underlined letter) and that it's properly linked to the textbox so that pressing the hotkey actually focuses it.
4. Make sure that the tree view is next after the textbox in the tab order.
5. Make sure that it's obvious how to cancel a search. You've already assigned Enter to performing the search (as opposed to closing the dialog) which means you can't use Escape because that is already required for closing the dialog. I think one way is to let the user empty the textbox and press Enter to clear the search, but you can also have a separate button as long as it has a hotkey and an alt text if it's just an icon. This kind of button is allowed to sit between the textbox and the tree view in the tab order, but make sure it stays that way and you don't add 10 more buttons there so navigating to the tree view becomes arduous.
I think it's ironic that I can give all of this advice just by being a keyboard user. I'm not visually impaired and I don't use a screen reader.
Point 1: I don't know whether tkinter's treeview has screen reader support. I will have to look into that. But what I did already do is to make it focusable, which it wasn't by default, I believe, and add controls like: up, down to select rows, pos1/home and end to go to first row or last row, space to select/highlight a row, I left right and left arrow key for opening and collapsing items, added enter and various other keys to trigger actions for focused row or all selected rows.
Point 2 I definitely have.
Point 3: I defined a shortcut (ctrl+f) that always focuses the text input widget of the filter, but I don't have a letter underlined in the label. The label is actually "Quick search" and not "Quick filter", which means I couldn't underline an "f". But also underlining any letter might indicate, that one could press ALT+letter to focus the input. Maybe I should add another shortcut to facilitate that and then truly underline the appropriate character. Maybe change the label to simply read "Filter" and use the "F".
Point 4 I have. The filter is directly under the treeview/table, and only one TAB away.
Point 5 I don't have, because as the user starts typing in the filter input field, the treeview/table is already being filtered concurrently. Pressing enter is just for when you want to repeat a search and not change the filter term. For example, when the words have changed concurrently due to other actions. There is no dialog to close, because this is all in the main window. I have been thinking about adding a dialog that displays a progress bar, or adding a progress bar in the bottom status bar of the application. There a stop button might be useful. But so far the searching/filtering finishes in milliseconds, so no one would have time to click that stop button.
It is a business opportunity as well. I worked at a company that paid for an audit before LLMs. There is tremendous cost savings possible here.
I also wonder if WebMCP will be the ultimate final incarnation of this.
Do you know one of the most underemployed groups are disabled people? And do you know where a number of disabled people get employment? Disability audits (unsurprisingly they're extremely good at this).
Congratulations on recommending further marginalising an extremely marginalised group.
But I'm not really a consequentialist and think of things in virtue ethics terms. And using technology to scale benefits to a wider group of people doesn't conflict for me. YMMV.
If society were perhaps more compassionate, and supportive of this group, then perhaps it wouldn't be so much of a problem.
As to your point about significantly improving accessibility of the web, we could do that right now, all of us, without "AI". We could have done that yesterday. Use semantic HTML, instead of injecting div-soup using Javascript into ad-riddled dark-patterned user hostile slop-pages.
"AI" (or accessibility audits themselves) are a bandaid after the fact. Accessibility needs to be baked in.
I wrote that a group of marginalised people would be further marginalised, and deprived of income and meaningful work in a sector where they are, by circumstance, subject matter experts. Anything else is projection.
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 piece) then that will likely encourage more enterprise to do it proactively, and will open the door for startups and mid-sized companies.
I have no idea why anyone would choose to see this as bad.
Sorry if that assertion stands opposed to your value prop.
No need to apologize, neither of us can predict the future. I am optimistic Fable-level models can succeed where the old not-actually-AI models failed. No shame in being pessimistic about the same.
It always ends up being faster, clearer, simpler, and better.
There is so much to learn in this space.
There are small things, like dropping a 'jump to main content anchor' before the navigation so you don't have to tab through the top navigation everytime.
But there are also certain pages en layouts which require a lot of thought on a good keyboard navigation flow. Combine that with the need for responsive layouts, our inexperience with accessibility tools, etc; and the required effort quickly adds up.
I ended up stuck on my back, bed-bound in 2005, with a keyboard on my thighs. Using OSX (probably Tiger) and mostly native apps it was possible to get by with just the keyboard. It was the only platform that I could use without a pointer and I was hardly pushing boundaries.
These days just doing simple things like setting up a computer for the first time, I often can't be arsed with a mouse, or I am in places where there isn't room to use a mouse. I have to resort sometimes to a trackball out of necessity, but it's always a hassle and I frequently hit brick walls. Simple file managers can be nightmare enough. I remember just trying to navigate to a taskbar on some desktops being impossible. I couldn't get to something like the network manager applet. Thankfully there's a CLI for that now.
On the flip side, I also love the idea that you can do most things with a simple pointer.
I was trying Batocera linux recently on a laptop, the touchpad wasn't recognised, it's a gamepad driven OS (I think a layer on retro-arch), and navigating with a gamepad (once you RTM and figure it out) is actually quite nice. Kodi, has always been a bit of a faff on the keyboard, and that works well with the gamepad. Kodi was born on the Xbox so this of course should be a given. The UI for me with a keyboard has always been a bit clumsy.
For accessibility (the topic of this subthread), TUIs are not like GUIs.
Can you explain what you mean by this phrase?
A common way this can fail is if the Tab key traverses through the UI elements in an unexpected order.
I was fired because I did too much once
So just echoing that this is not just an accessibility thing, but just a good user interface design thing. If your UX designer isn't taking keyboards into account (jettison mobile first development into the sun please) then they have no business building business applications.
We would have been murdered by at least the point of sale people otherwise :)
Power users would complain within hours
No, not really. I know what you are trying to say, and I fully agree. We need to stop using "democracy" or "democratizing".
Democracy, in it's purest form, is about mob rule --majority rule, if you want to say it in a softer/kinder way. "Democratizing" means giving a mob control of the thing, it does not mean making it accessible to all at all.
You're just parroting an old urban myth.
The terminus technicus for mob rule is ochlocracy [1]; democracy, per se, includes minority protections (i. e. if it doesn't then it isn't a democracy to begin with).
Democracy has nothing to do with minority protections. I don't understand you can say it per se includes minority protections. Democracy includes whatever enough people think it should include. If people don't want such protections then there is no need for them.
If a democratic society does not want to live side by side violent murderers and thugs they can agree on ways to deal with that minority group like killing them or imprisoning them.
You just proved my point by demonstrating your utter ignorance of the topic: Your three sentences are the textbook definition of ochlocracy (or laocracy), i. e. mob rule.
I suggest you read some authoritative and up-to-date texts on democracy before embarassing yourself again.
"Democratization" in a sense is about making things accessible for discussions. "Dictatorship" is the opposing term - things get "dictated" by a single entity - person, political force or a corporation.
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 slavery was a moral, social, and political evil.
In other words, take the time to at least do some research before you try to use quotes in support of a failed conclusion.
Did you read the Greeks in school? Probably not. I recommend Plato's Republic. Both he and Socrates talked about the flaws of direct/pure democracy that would usually make it degenerate into mob rule.
In Republic Plato developed a hierarchy:
Aristocracy: Rule by the wise (my comment: a fantasy)
Timocracy: Rule by the honorable (my comment: another fantasy)
Oligarchy: Rule by the rich (my comment: a reality in many societies)
Democracy: Rule by the masses (my comment: glad we don't have this)
Tyranny: Rule by a despot (my comment: plenty of examples of this in history)
So, "democratizing" means letting the masses have their way. It does not mean making things accessible to everyone, which is the hilariously or tragically ignorant way in which Silicon Valley tries to use the term. You see startups all the time say "we are democratizing <X>". Just how stupid are these people? They are saying we are going to let the mob have access and benefit from <X> not making it available to everyone.
In the context of Plato’s political philosophy the modern, casual use of the word "democratizing" completely ignores the historical and philosophical baggage of the root word democracy.
The irony is that modern society uses "democratize" as an undisputed positive term (meaning liberation and fairness), while the very philosophers who birthed western political thought used "democracy" as a warning label for instability and lawlessness.
A better term for what startups want to say would be "commoditizing": turning a specialized, elite resource into a public good or a widely available commodity; not "democratizing", which is an ignorant use of a term that means almost exactly the opposite.
I guess classical education has not been a part of schooling for quite some time. As a kid I did not necessarily enjoy reading the Great Books. As an adult, I can see how much damage has been caused by the abandonment of such valuable teachings.
As much as i do agree, overtime language does eventually change but it can happen over our dead bodies
Exactly, words do not carry their root's connotations as a permanent tax. 'idiot' used to mean "a layman, someone not holding office or lacking skill', or "a person not interested in politics"; 'nice' comes from Latin 'nescius', which meant "ignorant"; 'cretin' meant "Christian".
Democracy is not mob rule, and the Greeks agreed. They had a separate word for mob rule: 'ochlocracy'. Having two words means the Greeks did not treat them as identical. Plato and Aristotle argued democracy tends toward it, but they still have not treated it for a definition.
Bringing Plato here is kind of weird: The Republic is an anti-democratic aristocrat's argument, written by a man whose teacher was executed by an Athenian jury. Plato was born into the Athenian elite. His mother's family gave Athens tyrants whose regime killed something like 2000 citizens in less than a year. Plato initially was invited to join, he considered it, and pulled back when he saw what they did. He was part of anti-democratic coup. Citing him here for the word definition, is like citing Marx for the only definition of 'capitalism' - not exactly inaccurate, and might be even exactly correct, yet the context and connotation still matters - Plato took neutral-to-positive word and gave it a hostile reading, while Marx haven't even talked about 'capitalism' (he had "kapitalistische produktionsweise"), the actual term as we know it was popularized later.
'democracy' aside, "make accessible to all" is a long-established dictionary sense of 'democratize', it was never a Silicon Valley invention. And you're right - "representative democracy" only took hold in the late 1700s. The term's meaning moved after Plato. If democracy could shift from Plato's warning label to a thing Hamilton endorsed, 'democratize' could shift too.
I implore you, good sire (@robomartin), to unsaddle your high horse and let the language take its course - if people and times decide to give words different meaning, it most likely will happen anyway.
... And then your app turns into a canvas made in Electron.
It is an absolute train-wreck trying to get everything to work and for the overwhelming majority of products it isnt work the effort. It isnt like you put a wheelchair ramp up and are done. It is a constant battle with every change.
It is just another one of those things where the minuet minority suffers. Now if a company got some tax write off for it, that would change things.
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.
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.
It’s in the accessibility settings.
https://support.apple.com/en-za/guide/mac-help/mchlc06d1059/...
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".
I quote from Apple https://developer.apple.com/design/human-interface-guideline...:
> Always make context menu items available in the main interface, too. […] In macOS, an app’s menu bar menus list all the app’s commands, including those in various context menus.
Therefore one can rightly conclude that there is no need for a key to bring up a context menu.
This reminds me of frequent conversations with other developers when presented with a bug report. "That's not a bug, it's working as intended." The intention is wrong, then -- the bug is in the design, not the code, but it's still a bug.
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.
Apple's adding it to its own keyboards as well, at least on the third-generation Magic Keyboard with number pad (between F13 and forward delete).
Microsoft took accessibility of Windows and apps as a basic requirement. The fact that Windows is the daily driver desktop for the staff of the regulatory agencies that would bring complaints would not have gone unnoticed.
But really, why wouldn't you? You almost get it for free if you use the standard widgets, and smooth keyboard navigation is far faster for experienced users than having to repeatedly move one's hand between keyboard and mouse.
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.
This is even more visible when using Apple’s own apps on macOS. Choose any of them that have been ported from iOS without any attention to detail or any QA for accessibility, like Reminders or Settings or Notes or another app. The tab key will not take you where you might expect. There is no way to navigate only using common keyboard shortcuts. Nobody working on all these Apple apps have heard of tab order or keyboard based navigation.
Which ones, besides web frameworks pretending to be desktop ones? Most if not all frameworks I know support keyboard navigation.
Do Qt built-in widgets have huge problems? Inwould assume that custom widgets invariably do because approximately nobody writes any accessibility handling for them.
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.
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.)
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 from 25 years ago could be navigated at light speed.
That's part of the reason Excel can't be dethroned. Excel is from the old age of software, and that means that users can input and navigate at light speed. All these fancy tools claim to dethrone Excel, but when you actually use them you realize it's a goo goo ga ga Fisher Price level UI. Extreme amounts of whitespace, buttons hidden behind submenus of submenus (which you have to navigate by eye, by the way!), features stripped, UI constantly shuffling around between updates.
Look, that works fine for a website on the open web where you assume your users have never touched a computer before. That does not work for commercial software.
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
Devs consistently underestimate how many power users of Excel there are, and often don't understand how they operate.
She loved Pages, being able to put images anywhere without stuff moving around behind her back.
She hated Numbers, since there were no cut/copy/paste/undo buttons on the toolbar. This is someone who has been using Excel at work for decades at this point. Definitely had a sudden insight as to how differently many users work.
basically everyone uses Excel. And basically everyone is a MOUSE-first user (or, even further along the chain: TOUCHSCREEN-first)
keyboard-based menu navigation is not intuitive. it can be "poweruser" oriented, but it's not for most of the userbase
I'd be willing to bet that professional typists and people who spend the majority of their day typing (email, word, IDEs/text editors, etc.) are the ones who will know more keyboard shortcuts and navigation, especially for the things they do repeatedly.
and then 365 came along ... an option to pull stock market data here, a LinkedIn connection there, oh look a wild copilot button appeared.
This way it becomes easy to memorize key sequences; start by navigating with arrow keys, then eventually speed up as you memorize each menu item's mnemonic key, and if you ever forget, just look at the menu.
It was the keyboard-friendliest idea ever, without requiring any sort of terminal. I'd even say friendlier than MacOS (heresy!!) or, yes, VIM (burn the witch!!!)
So even if the developer forgot to configure mnemonics, which was as easy as prefixing a letter with ampersand, you could navigate by keyboard. Sometimes tedious but beats not being able.
> 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.
That's a very two-handed ableist view. Imagine having lost your arm and being told hitting three keys on opposite ends of the keyboard is simple.
I'm joking, but only about the calling you ableist and the emotional response parts. The situation does really occur. Keyboards aren't always the most accessible option.
(Hotkeys reveal mental limitations in myself. I can rarely remember them. I know a ton, but I've forgotten so many more. On MacOS in particular, when multiple modifiers are involved. Can never remember if it's cmd-shift, cmd-option, option-shift, cmd-ctrl, cmd-fn, or whatever.)
And trying to satisfy every audience at once is a good way to satisfy none. You don't want your app to be a Jack of all trades; focus is really valuable.
I think this is a bad reason. Even MS Office has made this work. But I've seen people act on this type of argument. If nothing else, it should be possible to have a settings menu where you can define your own. Even if no shortcuts are set by default and they aren't shown anywhere else in the UI, it will still be possible for a power user to make the best use of the program.
Underlining the accelerator key is subtle and shouldn't be overwelming. Keyboard navigation unaware users probably won't even notice.
> This works poorly if you intend to localise your application. Great if you don't though.
Sure that's true. But remember M$ allowed you to fairly easily edit those underlined-characters in, oh, for example Office 2002 and 2003. Even if you didn't have a lot of default underlines in your current language settings, it is still possible for someone to add their own underline-shortcuts.
Back in those days, the first thing I did on any personal new install of Outlook, was to disable the shortcut that marked all email as being read. (That's cause I hit that button by accident too many times.)
That's a feature that was hidden from me at least, but honestly, this is a good-ish solution to that problem.
I remember Office having the underlines, but they were inconsistent between the original English and my localised version (and I used both depending on the machine), which made them useless. That wasn't that big of an issue when all the normal keyboard shortcuts are also written out, but it would have been even less of a problem if I knew how to edit them.
Even for keys that aren't mnemonic, do you want undo to be ctrl + z or ctrl + the key closest to left shift?
Hence my original comment. I haven't had a problem with different keyboard layouts, since most of the keys that change are on the outer edge, nowhere near where the most common shortcuts are located (then again, I rarely type using QWERTZ).
> Even for keys that aren't mnemonic, do you want undo to be ctrl + z or ctrl + the key closest to left shift?
CTRL+Z, since that's what it's been since time immemorial, even on ISO keyboards. Consistency is king.
To be fair to your point though, that's what most localisation of programs are these days.
Every application did it for decades after the first Xerox guidelines up until Microsoft and Apple decided to retire the concept of usability some time around 2010.
That is not a requirement, having access to menus, a master help shortcut ir fuzzy search actions shorcut are other options.
Keyboard shortcuts should be an _optional_ way to interact for accessibility and power users! They should never be required!
This is what TUIs get wrong, they make it the required way to navigate and often don’t even let you use the mouse.
- Your mouse/trackpad breaks or isn't recognized?
- The right mouse button for your trackpad isn't working for some reason (e.g. you spilled a drink on it). It should still be possible to use the context menu keyboard button to bring up the context menu.
- Your hands are on the keyboard (typing a document, email, code, etc.) and it slows you down to move to the mouse/trackpad to perform an operation such as copying/pasting text or bringing up the spell checker context menu actions so you want to do those with the keyboard to keep yourself in the flow.
Most often you'll learn keyboard shortcuts/interactions for your workflow then expand out as and when you need them. Sure, knowing all shortcuts and interactions is fairly limited, but the majority of people will know how to cut/copy/paste with the keyboard as those are common operations.
My wife is a UX Design consultant and she had an engagement where a bunch of state government accountants were bemoaning how a redesigned procurement platform took away all their keyboard shortcuts.
Majority of computer professionals (programmers included) come to appreciate a single fundamental truth about their field way too late into their careers. That the most basic foundational unit, the substrate they need to conquer is text. Everything stems from it. We have to deal with text our entire lives. It doesn't matter where that text appears - in web browsers, in Jira, in Slack, in terminal, in PDFs, Word or LaTeX documents. Code by the way is just structured text. The feeling of empowerment and liberation when you can deal with text on your own terms is a disproportionate multiplier. That's why using multiple cursors feature for the first time feels so amazing, even though the practical cases for it are not that common.
And when I say "text", I don't only describe the process of "grabbing some text" and "piping it" into another process, or manipulating it. It's not only about the input, the act of consuming text is equally, if not more important.
We argue that keyboard-driven UIs are more efficient for the input, but hundreds of memorized shortcuts can't really fix the fundamental problem.
Vendors are designed to own you and ownership can take different forms. Slack app that doesn't let you easily extract code snippets from a thread - owns you. Jira that forces you to use their stupid, quirky wysiwyg editor - owns you. Note-taking app that keeps the data on the cloud ain't your friend. The friction is the ownership. When extraction of text requires effort, the tool has leverage over you. It's a subtler form than data lock-in, it is behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. Information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay there longer - search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates.
And when you get to that point, you'd feel helpless - all your knowledge and muscle memory can't help you there - not only the app is not favoring power-user experience, it's forcing everyone downgrade to the "average Joe" levels.
Most popular editors and IDEs don't give you direct leverage over plain text either, at least not without the effort from your side. Shortcuts, popups, UI elements in the IDE at best are local drivers - you can't easily grab a thing from the outside and feed it to your LLM context in the middle of a task, or insert within a comment in the code - you have to switch, copy, paste, deal with format inconsistencies, manual conversion, etc. Then we keep bargaining what method is the best, fastest and most convenient - using the mouse or keeping the fingers on the home row, modality or complex shortcuts. All for the sake of the problem that's artificially enforced on our workflows.
Terminal-heavy users eventually start appreciating the leverage Unix philosophy grants them over text, but that's still contained within locality, they still have to constantly jump around, while eventually figuring out ways for automating some aspects of it.
Point is - do not give in to the status quo. Liberate your text - deal with it on your terms. Get annoyed whenever you need to switch back and forth just for the sake of finding the piece you need and moving it around - it should be instantaneous and instinctual. Like a boxer moving in a ring and casually throwing heavy punches. Long-time Vim and Emacs users "get it", even though they often don't follow through - some things just never become gratifying instincts. Sometimes, even the opposite forms - like redundant muscle memories. Some outright would reject using a new app because it messes with one shortcut they keep accidentally pressing. Sometimes, I wish there was an agreed standard for every UI - to have only the core, commonly used keys pre-set, while making everything else configurable.
Push a button, every icon is now labeled with a key, type that key, counts as a click, done.
I get that this does NOT solve for say, someone who's blind (i guess you could announce them, not sure), but it is easy enough I've found even lower tech people are fine with it.
As always, a lot of the trick is communicating the interface and using modern standards, not "Well it's ctrl + insert because that's what it is on linux"
God forbid I should ever be forced to use Blender or Inkscape with only buttons.
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 nothing.
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.
It should have been Ctrl-Backspace or something.
About enter to auto submit, i've been running into this problem more often where some web frameworks just ignore the Enter key. There is a submit button, but i cannot trigger it via the enter key.
It's also far less likely to be accidentally typed while trying to fill in a form and fumbling the tab navigation.
Because alt+left is a better choice? Really f**ing annoying when some dumb javascript removes focus from a text box you're editing and the page navigates back.
I can kinda get that one.
Because web pages don't preserve element focus well, web was originally meant for documents in the first place, not UIs. If you're trying to erase a character and the focus has been lost, you go back in history instead. It's a real existing problem in poorly designed pages, not a nefarious plot to annoy power users by Google, Microsoft, or Mozilla. It was always janky as hell.
There's nothing wrong with a keyboard driven UI having buttons as long as they advertise their key, though. That's one way discoverability is supposed to work. It means you can fall back to the mouse when it makes sense.
With ribbons, the menus were gone and the toolbar buttons became the "ground truth", but in a much more haphazard way.
Fuzzy command search goes a bit back to menus, but as you say in a way that's much less guaranteed to be stable.
You mean because they're basically just in the way, right?
I know it's asking a bit much, but IMO advanced software ideally has
- buttons, pretty colors and icons where they make sense
- keyboard shortcuts for everything
- complete documentation that ships with it (sure "it's online anyway".. so find a way to automate putting what you have on the website into the release in a form that works offline)
- preferences to hide some or all buttons/toolbars, turn off the icons, and change some or all keyboard shortcuts. GUI is cool for that, text files are also cool. In other words, why not have everything? Maybe you could even compile a version that strips out all the stuff that can be turned off, or at least hardcodes some preferences, so the compiler can skip some things that are no longer called etc.
Not a must-have but nice-to-have: tooltips for all things and maybe advanced help, so you don't need the documentation as much, or not at all for simple use cases. But if the docs are complete, I think it's fine to keep the program and development process simpler by not duplicating that in tooltips. Don't go out of your way, unless you want to.
But as I said, that's for "advanced software", by which I mean software you spend a lot of time in. Browser, text editor, email client, file manager, graphics software, and so on. With simpler tools I'm usually just happy they exist.
I don't see why removing the buttons would be desirable. All that would do is to make the GUI unusable with the mouse and also make the discovery of the keyboard shortcuts much harder.
I'm a longtime Emacs user and I detest tools like VSCode (VSCode in particular) because they aren't fully keyboard driven. "Fully" is the important part here. You can do a lot of things with keyboard in VSCode, but every now and then there isn't a way to do what you want without the mouse. And it screams "bad (no) design". For example, jumping between different panes in the editor is not always possible without a mouse, or the path to doing it is too long.
Before my attempt at generalization, I also want to address these:
> UIs like CLI or TUI suffer terrible discoverability
They typically do, but they don't have to. The reason for making a CLI and, to a lesser extent, TUI is the development speed. A full graphical interface will take longer to develop. So, whoever ends up making a CLI or a TUI tends not to invest time into accessibility either, because their goal was to save time on the UI in the first place.
Another aspect of this problem is the baseline knowledge. Users of graphical interfaces know how to discover functionality, they recognize familiar controls and patterns, they know that a cogwheel icon is likely to be a gateway to a program's settings, that if they want to make their changes persist, they need to look for something that looks like an open folder, or maybe a diskette icon...
Emacs has absolutely amazing discoverability. No program with graphical interface ever made doesn't hold a candle to what Emacs can do. But the user needs to have the baseline knowledge to... ironically, discover the discoverability. And I don't think there's a way to bootstrap from this problem. The minimal knowledge necessary to discover Emacs' features must come from reading the manual or asking a friend etc. Just to give you a few examples: Emacs can easily display all, without exception, keys and associated functionality available in the current editor's layout. It can also display them per individual component (if you, for example, knew that a key was defined, but was missing from the aforementioned list). You could also use the function name, if known, to find what key it binds to in the current layout. You can easily discover what any key (combination) does in the current layout without actually trying it (rather reading its documentation).
> can we have a keyboard-driven UI that is as intuitive as clicking with a mouse?
Absolutely! If we commit to a general set of rules that allow bootstrapping. This would require a degree of uniformity between such tools and, perhaps, some visual or even physical aids in the computer periphery to make this work. Computer interfaces, both physical and on-screen, evolved to support mouse-first UIs. For example, the navigation arrows on the keyboard are virtually never drawn on jklm etc. The keyboard is presented to its users as a tool solely designed for entering text, not a tool to engage UI controls. Compare this to gamers' keyboards that often emphasize wasd keys (because they are often used for moving your character in games) or even more extreme designs like Nostromo that are geared towards typical game interface.
* * *
Being keyboard-driven isn't about, as you said, having a shortcut assigned to an action. This is not how good keyboard-driven programs work. This is the way of thinking if your baseline experience is a GUI, which must be somehow retrofitted into the world with the keyboard as a primary driver.
Keyboard-driven, to me, means that the program has a systematic, hierarchical and consistent approach to deal with the keyboard input. Assigning keys to actions at random will quickly overload the user's ability to memorize such bindings. A keyboard-driven program is designed to have a system that the user can internalize and use to predict the right key for the desired action. Such a program should make no exceptions when binding actions to keys: any action should be accessible in a reasonable small number of keystrokes.
Edit with Copilot[1]
Press the Copilot key on your keyboard[2] and type the thing you want to happen on your keyboard in English without leaving the home row. Forget the keyboard shortcuts, the path through the menus, the button location in the toolbar, the command name in the omnibar, the marketing name of the feature. Forget queueing up keyboard keys in an input buffer based on memorising which dialog will popup next, or the tab ordering on this or that screen. DWIM is back, and this time it still isn't determinstic, but it's the way we are going to manage ever-growing software features and task complexity and finally turn computing declarative instead of imperative.
"Move rows with dates from 2020 to the bottom of the table"
"Change the date format in the table from mm/dd/yyyy to yyyy-MM like 2026-Aug"
"Style the table with alternating dark/pale contrasting colour backgrounds and a different header row colour"
[1] https://support.microsoft.com/en-us/word/edit-with-copilot-i...
[2] https://blogs.windows.com/windowsexperience/2024/01/04/intro...
I also think this is misunderstanding "discoverability" a bit. For me "discoverability" also means you get an understanding of what options are available at all in the system, which can be helpful to get a better idea of what you want to do in the first place.
Seach and chat-based UIs always assume you already have a perfectly thought-out plan what to do (conveniently in terms if the software you're working with) and just have to type it in.
Screen readers allow users to use their keyboards and other assistive devices to navigate websites and apps by tabbing through elements with extra controls and shortcuts to skip to regions, interact with elements and such.
To that degree I agree that all GUIs should be keyboard accessible.
This is obviously not what the original author had in mind, if he had to tab through every item in a web app he would probably get frustrated rather quickly. What he is imagining is like TUIs where all the interactions are through keyboard shortcuts and macros. These are not popular with the majority of users of modern day software, especially if the software is something that is used infrequently. I think we take for granted how component we, people who create software, are.
What has become more popular are interfaces that expose extra controls with a single key press, where the user can type to get the result they want. So instead of memorizing the keyboard shortcuts to dozens of actions, you can press something like Crl+K or / to summon a palette where you can search for the action.
No clutter, but hints come as you stutter on what to press next
Some examples of what you are asking for can be found in videogames due to controllers
[1] I was going to link to a repo, but I just learned that which-key is included in Emacs out of the box.
For literally decades after they were state of the art, people who used old-school mainframe TUIs would still swear by them.
I think the key difference is that they would buffer inputs. You could be on the "Receipt" screen, and know that if you needed to enter the code for some rebate receipt or something, you could hit F6 - F2 - down - down - down - {start typing code}, and even if the UI took multiple seconds to actually get to the point that the code was being entered, the input would be kept.
Normal GUIs have discarded this for fairly good reasons. Especially when it comes to queuing mouse clicks. If you get down to the nitty-gritty of what it means to queue a "mouse click" it get very conceptually complicated. But you could create a GUI toolkit that still had the same idea integrated into it for a keyboard interface, if you have well-defined points where you are and are not accepting keyboard input.
I would submit that "keyboard-driven UI that is as intuitive as clicking with a mouse" is actually the wrong direction to cut on. You need to beat the conventional mouse GUI completely in some other dimension, one where it can't even compete. This is the only one I know of that has historical precedent.
The downside is that on a desktop I'm pretty sure you're looking at a completely new widget toolkit. Trying to force this on the current ones is going to be hard and could even be impossible.
If I were going to create a new web frontend framework, this is what I'd focus on to have an actual new feature that isn't just a respelling of the current set of features. And I can't guarantee that it won't also be missing something crucial, though, I think everything you need is actually there. You could even have modern nicities like, store the entire GUI field state transition diagram statically at the beginning and as the user types ahead of the GUI's current state, show them a rendered view of where they are going, e.g., the key sequence I showed above could be "[Rebates] -> [Rebate Receipt] -> [Name Field] -> [Address 1 Field] -> [Address 2 Field] -> [Rebate Code Field] -> [Entering {'A8F2-132A-9283'}]", live updating as it goes so if the user can just bang that out even while the first screen hasn't loaded they can even be sensibly editing the text input they're going to put in.
Combined with something as simple as making sure everything always has a keyboard shortcut in a defined format, which is conspicuously displayed every time you change something, e.g., every time the user clicks the Rebate Code Field you can also display something like "Ctrl-F R" or something so they also learn how to drive the screen with a keyboard and you would, if nothing else, have something different than what's out there today.
Anyone who wants to, steal this idea. I'm not going to do anything with it. I don't see this as something you want in every app necessarily, but people who spend hours a day in the same app for whatever reason would be confused for a week, then I bet you couldn't pry it from them with a crowbar.
Keyboard input can, when designed well, be fully predictable and require no feedback loop with the computer. The motor movement involves a fixed set of physical buttons, which we can fairly easily train to press very reliably, and that training is then universally applicable across all software.
That is why you can buffer keyboard input but usually not mouse input. With keyboard input, I know what the software is going to do and I know exactly what hand movement will get it to do the next thing, so I can perform that movement even before it's ready. With mouse input, it's not really possible.
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.
I think what's also needed is a standard way of navigating what I guess I'll call the "focus tree". For example, if I'm running Vim inside of a terminal multiplexer (eg: Zellij) inside of a terminal emulator inside of a tiling window manager (eg: xmonad)...
It would be GREAT if I could use Vi keybindings to navigate windows in whatever "focus layer" I'm at... and then have a "standard" keybinding to navigate up and down that tree (eg: "Ctrl + >" and "Ctrl + <").
Right now, everyone seems to solve the "focus tree" problem by trying to choose a control key combination that won't collide with any other process that might be listening for key chords at the same time.
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.
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.
it was a webapp framework, but... all browsing/listing screens included row ids and a focused text box- so that typing the row id and enter would select. all action buttons had an underline to signify which ctrl-shift hotkey triggered them. all edit screens defaulted focus to the first editable textbox and at no time was the mouse actually necessary. finally, load times were optimized to target 75ms.
amusingly, the user feedback was "the keyboard control is pretty good but can you please make it faster."
what i thought was chrome ended up being critical to the users not being miserable.
Although where possible software should be easy to learn for lots of programs the user can expect to use the program lots those ones would improve productivity of the user by focusing on speed of use for the user not discoverability and intuitive. Again there is plenty of intuitive design that is also fast once the user becomes familiar with the system but the discoverability and intuitive aspect is weighted higher then speed of a knowledgeable user.
I do think lots of programs would benefit from being more CLI accessible and allowing users to build scripts that lots of modern propriety programs do not allow you to do, at best they have some script engine running in the program that you can call with more effort then it should.
But the broader trend in GUI apps has been to target marketshare not deliver productivity for keyboard users. Back in the 80s and 90s Photoshop, Illustrator etc. became the powerhouses they are today because they focused on allowing professionals to be extremely efficient using their array of powerful keyboard shortcuts. In 2026 when software companies are dying of KPItis scoring their product management on creating compelling subscription models to hook customers, attention to actually delivering productivity for keyboard users is often an after thought. Mobile apps don't have keyboard shortcuts and desktop apps seem to increasingly be treated as as the narrow "edge case" with only a few hundred million target users versus the billions available on mobile devices. It's an opportunity for those who get serious about delivering value by leveraging the power of keyboard shortcuts to make their GUIs highly productive and comprehensively usable from the keyboard. For all their faults, Microsoft got this right with VSCode.
> But the broader trend in GUI apps has been to target marketshare not deliver productivity for keyboard users.
It's not a trend, it's a fallout of Electron being the default choice. Devs that use non-web UI frameworks are aware of keyboard navigation, or at least don't disrupt the builtin thing. And of course what devs that don't target power users tend to do is irrelevant to GUI vs TUI debate in the context of power users.
Something to consider is a terminal that has keyboard navigation of its own. Through a terminal shortcut, I can move the cursor at will and copy any text at all, even if it's part of the interface of a TUI. If I want to copy the filepath of the file I'm working on in vim to then use in a shell, for example, it takes like 5 keys to copy it straight off vim's statusbar. A graphical text editor can display the filepath in a tab or something, but I can't copy the text off the tab.
I don't know if I'm alone in this, but it's very frustrating to want a piece text, see it in front of you, and you can't copy it because the developer for one reason or another didn't implement copying of that text, so you have to type it out even if it's right there.
Sometimes it seems on purpose too. For example, when a game on Steam gets updated terms of use, you get presented with a window showing the terms, but you can't copy them to save them. It's like the purpose is to just accept and forget the terms. A TUI can't prevent the user from copying text by its very nature.
Any terminal can implement this kind of arbitrary-text keyboard navigation on its own and have it work for all TUIs. Were e.g. GTK to implement something like this, it would only work for GTK apps, not for all GUI apps. This is exclusive of TUIs because TUIs are text-driven while GUIs are pixel-driven.
Funny but I struggle with copying anything in most recent TUIs. Fancy padding or multiplexer borders and multiple lines of text? It breaks. Incomplete text in a spreadsheet column (tabiew) or a narrow internal window? It breaks. Ohmypi literally has a separate command to copy the prompt because of that, and another command to copy the model reply. TUI is just a poor choice here, it doesn't play well with formatted text like markdown, UI controls, long text, and so on. Terminals are good for CLI where the text is presented as lines, not TUI with spaced layout.
>Any terminal can implement this kind of arbitrary-text keyboard navigation on its own and have it work for all TUIs. Were e.g. GTK to implement something like this, it would only work for GTK apps, not for all GUI apps. This is exclusive of TUIs because TUIs are text-driven while GUIs are pixel-driven.
Terminal navigation has nothing to do with TUI navigation. Most TUI apps suffer from terrible NIH and end up with their own homegrown incompatible keyboard navigation schemas you need to learn every time. Of course absolutely nothing prevents you from writing a TUI framework with a common schema, at which point you will be at the mercy of the dev using this or that framework and schema, same as with GTK and Qt. None of this is unique to TUIs or GUIs.
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".
For example a GTK app main context menu can be triggered with F10. But this relies on the developer to correctly "tag" said context menu.
In simple cases it is obvious what to do, but in more complicated designs, where you may be able to achieve the same visual output in different ways, it may not be so obvious.
In that case, it is up to the developer as well to read and try to follow the published guidelines.
(not that the tags shouldn't exist, they can make customization easier, just that they shouldn't be necessary for any framework menu components)
What complicated designs do you have in mind?
I would argue that any sufficiently powerful framework also provides more ways to diverge from the "proper way", so it puts more pressure on the developer to actually study and understand the framework design patterns.
And more pressure from more options doesn't follow, you only need to study if you actually want to diverge
The "conditional" is carrying a lot of weight here. The developer needs to know what to do. For example, in my GTK application I had to learn how to identify a menu as the "primary" menu, so that the framework will automatically bind it to the well-known shortcut.
<object class="GtkMenuButton">
<property name="primary">true</property>
Then, you can go into a different discussion. How does the framework guide you to the correct functionality? Does it force you to include a primary menu? Does it check that if you have at least one menu, then one should be primary? What if the developer creates an unorthodox menu by creating a simple button that opens a popup with a list of buttons?
No he doesn't, your primary example is the same thing - your menu is uniquely identifiable, so a user can configure F10 to open it if you, app developer, forgot to mark it as main (by the way, how did it compile if you have no main prop? Then it's not easy to forget, "framework guide you to the correct functionality?" indeed)
> What if the developer creates an unorthodox menu
What is he draws a circle instead of using a letter O? What of it?
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.
For example, in Firefox, trying to save a file when a file by that name already exists, you get a "Cancel" or "Replace" prompt and you can "Cancel" by pressing return, but if you want to "Replace", you apparently HAVE to use mouse or trackpad!?!
The folks who learn how to use it well navigate through it faster than the system can process their inputs.
The new system has lots of fancy GUI, but is slower, and the folks used to their shortcuts hate it. But it's so much faster to train people to use.
I wish this was a default, but also that there was more of a standard to navigate UIs. That's why I really like vimium and other similar extensions, it's following the vi logic across websites, rather than having to learn everyone's idea of how to navigate.
One of my main issues with KDE is that the default keybindings for desktop operations feel like they were designed by people who don't navigate their desktop with a keyboard.
Then there are little things like in Gnome the screenshot implicitly copies to the clipboard, while in KDE you have to click the copy button. There are just little points of friction I experience in KDE that make me yearn for Gnome's workflow. I think my ideal world I would have a KDE desktop that used all the Gnome shortcuts, and worked more like Gnome.
"It should be possible to move around and interact with every part of your user interface using the keyboard."
Yes, finally. It works both ways; when I have hold of the mouse, I don't want to reach for the keyboard, and vice versa. Windows has had this problem for ages, and probably always will. There are some workarounds, "ctrl-esc" (I do this all the time) and "windows-button", but some of them require really jumping through hoops.
- Tab to move across fields.
- Left-to-right, top-to-bottom focus.
- Space to toggle togglable stuff.
- Alt-Down Arrow to deploy drop-down stuff.
- Arrows to move around.
- Enter/Esc to accept/discard a modal.
Or maybe I misunderstand the things you call "mouse things".
Keyboard design is much more, its also about how and where to place items, how things should move... it's a whole world. In the mouse world we have "discovered" those things and now we "just copy" other designs that we know work fine.
If this grid a central component of the application and navigation inside it is very common, I would argue that there should be a way to quickly move around the cells. The "how" is up to the specific application and the paradigms it promotes. For example, line navigation in vim is possible with "<N>G", but such a shortcut would seem absurd in another application.
- Spreadsheet-like stuff: arrows, PgDn, PgUp, Home, End, … move inside of it.
https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface...
Your resource mostly describes how to make keyboard-based workflows accessible. But just because the full functionality of an app is keyboard accessible, doesn't mean that it works as well as the pointer-based approach - especially if you have an app with multiple menus, sidebars, headers, footers etc. Maybe you could tab through everything, but a pointer will be faster. This is where a "keyboard-first UX concept" is missing (from GP).
I think an interesting idea to solve this would be a "focus navigation mode". Enter this mode with 1 shortcut and then navigate between items with a few keys; like a combination of mnemonics and screen reader navigation e.g. jump between headers with "h" etc.
I mean something like this (my wip keyboard-first file manager): https://ibb.co/G3WBW5C1
The hard part is, there seems to exist no UI & UX design language I can follow to create a nice keyboard-first app, so I have to think through everything (which is fun but tiring).
I don't know about 'first' because I don't see a reason to privilege keyboard workflows over mouse workflows given how ubiquitous the latter is but Windows has had, for literally decades a 35 page Keyboard UI spec. They've put a fair amount of effort in applications being navigable in a consistent way.
https://learn.microsoft.com/en-us/previous-versions/windows/...
Sadly, macos keyboard navigation is dwindling in interactions like the screen sharing pop up when you plug in a monitor
It occurred to me that this is a wonderful way to design software: you immediately know the keyboard shortcuts because you’re already looking at them. I’m working on taking what I’ve built for the qwerty midi keyboard controller (which is built on hammerspoon) and making it just a generic interface for any kind of app.
If the end goal is navigating and controlling the app via keyboard shortcuts, so why not bake that into the design of the GUI itself?
My project if you’re curious: https://github.com/mattdanielmurphy/qwerty-midi-hammerspoon
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.
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.
How to exit is literally the second thing `vimtutor` teaches you, after hjkl cursor movement.
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.
- New *G*ame - *S*ettings - *Q*uit
Ideally keys should be centered around an area of the keyboard and not just the first letter.
always happy to hear from people like that if there are things we can improve.
(people who just don't like using mice need no such encouragement to share their opinions :) )
And it's auto generated from the UI code. It still surprises me how many people just prefer the mouse anyway, though. But the option is there!
I've found that that itch is pretty much entirely solved by Sway (especially since it supports modal navigation, which I have become pretty addicted to), but honestly I actually found Gnome Shell (as of about ~2 years ago) pretty keyboard friendly. Hitting the Windows key [1] brings up the global search and that worked to launch stuff, moving between workspaces worked ok. I know it's popular to hate on Gnome 3 and beyond but honestly I rather liked it.
[1] Or whatever the official name for it is; it's a Windows logo on my keyboard.
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.
Going back and forth between the keyboard and the mouse is what's awful about bad interfaces in my opinion, not the mouse as a pointing device.
When I developed KeenWrite[2] over 12 years ago, I chose JavaFX because it was (a) bundled with Java; and (b) ran on Linux, Mac, and Windows. JavaFX was later ripped out of Java, to my chagrin, forcing a number of technical contortions.
[1]: Not free on Windows due to Microsoft's $500 cert signing process.
I also can't cleanly nest and stack GUI applications in tmux like I can with TUI programs. I think GUIs are for the most part tailored towards non-power users unless its something like video editing or 3d modeling that is aimed more towards professionals
Sounds like a window manager problem
And it should also be easy to make the keyboard controls customizable.
I move much faster when I don't have to take my hands off the keys to nudge the rat.
However, I don't think my preference for TUIs is about my efficiency. The most important reason I love TUIs is that they generally only have a base set of features needed to get the job done. Most GUIs go off the rails, implementing features for use cases few people have. TUIs tend to be small, fast, and focus on a small use case.
So even though I started out claiming I love TUIs, what I really love is small software: CLI > TUI > GUI.
This way I can quickly repeat an action from the past. I get a history of commands inserted. _And_ I can bind my own keyboard shortcuts if necessary. TUI and GUI do not meet this level of platform independence.
If a tool is TUI only I will not adapt it. That's not the case with a GUI, though.
(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)
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.
Far beyond mouse, stylus wich are themselves infinitely superior to touchscreen.
Also a lot of webpages have it already built in, by pressing "?" they show a nice overlay. For example github and gmail have it.
For github I still ended up adding a quite a few more shortcuts.
Same thing I hear from everyone.
"You can't compromise on UX" - UX experts.
"You can't compromise on security" - Security experts.
"You can't compromise on Accessibility" - a11y experts.
We gotta make trade-offs, and I gotta get my thing shipped (for me I learn toward security for my service)
You could compromise on not-shipping-before-it's-ready.
while being better at QAing i finally get the time to work on the things that got me into programming in the first place, which in the point where human interact with the machine.
Love it.
I still haven't found generic solutions to selecting and copy-pasting text using the keyboard only though, when the text is not in a textbox/area.
I had used a vim-like plugin in firefox that let you do that somewhat, but nothing OS level.
Even crude AS400 days keyboard UIs were beyond nice. But then if people want to try and replicate emacs keymaps or vi command composition, better for the dozens of us. ^^
Bitwarden used to be keyboard friendly, but recent updates have removed those functions for reasons I can’t understand.
Like anything else in life, I think there's no single answer to this.
But for people interested in seeing the difference between mouse-driven vs keyboard-driven flows while web browsing, check out the Vimium extension. It made my sentiments very much favour keyboard-driven workflows
Keyboard interfaces can be, but not necessarily, quite opaque. There's a reason in the old days companies shipped keyboard overlays and function key templates to help users (or went all in with custom keyboards built for the application).
In contrast consider something like Wordstar where you pretty much just needed to memorize the three prefix keys, and if you pressed one and waiting, you'd get a menu describing all of the options.
Obviously, things like early Smalltalk and, probably, Xerox (having never used any of the early Xerox systems), relied heavily on the mouse, but even it had command accelerators.
The CUA standard was that crossover that Windows, and MOTIF, adopted. Much of that work is still with us today, and it worked well both on GUIs and TUIs (witness the old Turbo Pascal/C++ IDEs, and other applications). Those character based applications had to assume there was no mouse, but offer the flexibility of being good citizens should a mouse be present.
The "intuitiveness" argument is also related. You cannot rebind well-known shortcuts to different actions and expect the user to not get frustrated.
I would love a return to function keys. You get 12, make 'em count.
At least, this is the way it's always been on OS X and later. I'm not sure about classic Mac OS.
Hacker browser: allows to navigate browsers without ever needing to use the mouse.
I highly recommend it, it's such a productivity booster
For me personally it goes I like TUI/CMD for things I use as a daily driver, I know what I want to accomplish I know exactly what movements to do and clicking GUI items is just too slow.
Then there are GUI things that I don't use that often I need some kind of map, I don't to "read the fucking manual" every 3 months when I use it and I barely remember, but if I see it in GUI my memory will kick in. It also works for most new things better than TUI/CMD because for a new tool I don't want to invest my focus, I just want to find out how to be done with my things or just learn what it is, reading manual is not fastest way, fastest way is clicking around.
Nowadays we have 3rd mode namely "chat interface" I can just chat with whatever bot is integrated in the app or just chat with the bot to use the application for me. Command line utilities work like charm in that mode I can accomplish a lot by asking vague stuff to a bot that will make stuff for me in a ways I don't even have to know how or what.
But I do believe final form of interface is not "chat interface" alone. I do believe what Karpathy already outlined, that there will be specific interfaces for systems that will use GUI elements to make it clear for the user what is going on and will be faster to clear the information to the user instead of having user to read back text.
I just prefer TUIs, I think if you prefer GUIs you should very much use them and ask for more of them, but if you prefer TUIs please do use those too. I could go into all the reasons I prefer TUIs but this is a HN comment not a manifesto.
Please just use and develop what you prefer.
Every action was keyboard first and only got mouse access later. Browsing by keyboard is not the browser's specific goal, but it was a feature from day 1!
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
Yes. One problem with this argument in particular is that every TUI reinvents the wheel and designs its own schema.
To reinforce author's point, classic GUI frameworks and their guidelines actually provide hotkey schemas for common actions by default, and hot paths for quick interface traversal. They're universal and work by default, so in a lot of cases you don't even need to think about it, only extend it with your own actions. Absolutely nothing prevents you from doing the same in a TUI framework, but at this point the supposed simplicity and flexibility is lost.
New GUIs have other innovations, see for example Microsoft Ribbon that adopted link navigation from Vimperator to make classic toolbars discoverable, compact, accessible from the keyboard, and customizable - all at the same time! Unthinkable for any other UI paradigm.
It's incredible that after the Electron devastation era this unification and keyboard accessibility feels like some kind of lost art, and the perceived lack of keyboard driven GUIs is used a strawman to criticize GUI as a principle. Status quo of "most apps do X" is not the principle. It's also not true, essentially all good GUI apps are keyboard driven, and surely most professional/heavy user ones.
Design good interfaces, not bad ones, regardless of the paradigm. This is harder than it seems, and TUI is not a automatic substitute for your lack of this skill. If you think it is you will design a bad app, in the same way pixel art looks hideous when used to compensate for game designer's laziness. In fact, a lot of recent TUI apps I see are pure terminal cargo cult and are simply worse by being TUIs.
All UI's should be tab-able, but that's still a miserable experience for keyboard users. A keyboard-centric UI must provide instantly discoverable shortcuts. Possible methods:
- Put all elements on a grid so that they can be navigable with the keyboard. This is a significant restriction for the designer.
- Put keyboard shortcuts next to every button. It's not enough to put them in tooltips (*cough* Raycast). Common in games, but wastes space.
- Add a Command Palette. This is the easiest, but it requires mirroring every action, and is suboptimal when you have the same action for each item in a set.
When designing for technical users: all of the above please. But for average users it's less clear. I think there's still room for innovation, both on the software architecture and the UI side.
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.
Interestingly, people have seen my GUI Emacs and commented "I didn't know you could get images in a terminal". Then I have to tell them it's not a terminal...
If I had to pick the absolute worst things about Teams, which is already one of the worst pieces of software ever made, it would be that it's not keyboard driven at all.
The way we are moving I believe soon we will be talking to the websites not just clicking or typing around...
I tend to deride UX/UI as almost a joke because it nearly never understands that fashion and science are different things.
This one gets it.
Excel is the same way. I’ve been an excel power user as well as a Sheets power user and the latter just never managed to enable the level of speedy keyboard navigation Excel could. I can almost work blindfolded in Excel.
I mean these things aren't only highly usable, they're absolutely beautiful[2].
I'll also add that being keyboard driven helps people with disabilities AND makes things easier for AI agents. For exactly the same reason too. It's far easier for programs to hit key codes than try to determine pixel locations on a screen.
As a "power user" I still love TUIs but I also love good GUIs. Why should I be constantly lifting my hand to reach for the mouse? Though one of the big reasons I love living in the terminal is that it is extremely light weight. So many GUIs just eat up your system resources. I don't have that issue with TUIs. FFS, just compare 2 editors: (neo)vim vs Word. And before you say "Word does more" go ahead, add a hundred plugins to vim and then run that test again. vim will still win while also replacing VS Code, Obsidian, and a dozen other applications. The other big reason I love it is portability. Like the author mentions and is discussed in last week's thread, I can jump between machines (even through ssh!) and have no friction. I can have full control of my machine through ssh in a TUI while my mouse jitters while streaming the screen through either ssh or a VNC. I literally have to set different PS1s on my machines because otherwise there's no feedback telling me I'm connecting to something locally vs remotely.
But more importantly, let people do what they want. If you prefer to live in GUIs, do that. If you prefer to live in the terminal, do that. What's great about computers is the choice and flexibility. A big reason I'd support the OP here is that it exclusively adds to that. The ability to program computers and make them do what we, a random user and not an employee at some big tech company, want them to do is what made them take over the world. That even includes smart phones, where no two are alike (you all have different apps). Let's just make good products and let the best ideas flesh out. That's better than just arguing. I don't care if you use emacs, Atom, or program in fucking notepad++. You do you. But as devs we should add flexibility, not put people into boxes.
The intuitive part of my argument also falls under this. By following known conventions as close as possible, we can eliminate the need to remember the most common actions.
Additionally, it is important to present your shortcuts in a shortcut window/dialog in a logical way for when the user needs to remember something.
In any case, an excesive number of keyboard shortcuts can have a negative effect on usability, so this is also important to keep in mind.
This does not contradict the argument. The rest of the interface, everything that is known and stable in advance, should be full keyboard-driven.
Objective would be making the statement that not all GUIs need to be keyboard-driven manged or have accessibility built-in.
Example, GUIs in automation are primary touchscreen driven and have user requirements base on the environment they are in.
GUI standards are objective to who the users actually are or will be.
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.
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.
I think, firstly, we need less meaningless red-tape shenanigans from MS/Apple to publish GUI apps
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.
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.
CLI pipelines are obviously not a real solution to, for example, arbitrary text editing, especially if you don't know what you want to change until you see the text.
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.
nobody cares about the web layer
Keyboard shortcuts, navigation, and more are inconsistent in web apps. Will they work at all? Will they use different keys? No one knows. Will they respect my OS theming? What about my font choices or font sizes? Almost certainly not.
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.
GUIs should be fully keyboard-driven
https://ckardaris.com/blog/2026/08/28/keyboard-driven-guis.html