Hook: On August 28, 2026, a manifesto titled "GUIs should be fully keyboard-driven" exploded on Hacker News — 1023 votes and 502 comments for the idea that every graphical interface must be fully keyboard-operable. What caught me wasn't the content (it's obvious) but the timing of the debate. This text is an almost character-by-character copy of an IBM manifesto published in December 1987: 328 pages called Common User Access. The irony is that over the past forty years, the industry has tried everything — DOS, Windows, web, touch — and each time with remarkable stubbornness threw the keyboard out of the equation, then quietly brought it back. The 2026 debate isn't a debate, it's a relapse. I wanted to understand why the relapse is inevitable: why the industry kills the keyboard again and again and resurrects it again and again, and why this time the keyboard might need a graphical interface for the first time.
Late autumn 1984. IBM shows an updated PCjr — a machine the press had already written off as a failure because of its rubber Chiclet keyboard. But the update had a surprise: along with a normal keyboard, the PCjr brought the world the first public appearance of standardized keyboard commands: F1 = help, Esc = cancel, F10 = menu. Three commands that today are known by anyone who's ever hit F1 in panic. This was IBM's first attempt to introduce unified keyboard commands: a single keyboard language for all DOS applications.
Two years later, IBM officially established the Human-Computer Interaction Committee. The task sounded bureaucratic but was revolutionary: force the entire industry to speak one keyboard language. A year later, the committee produced Common User Access — a 328-page specification published in December 1987 as part of Systems Application Architecture. CUA wasn't a "guideline" in the polite sense — it was a standard, the same by design as Apple's 139-page Human Interface Guidelines from 1987 for the Macintosh: one menu structure, identical keys across all applications.
Funny to remember now, but in 1987 CUA solved a problem we don't even perceive today: before it, every DOS application was a separate civilization. To open a file, you had to remember a separate sequence for each program: in Lotus 1-2-3 — /, F, R (Retrieve); in emacs — Ctrl+x Ctrl+f; in vi — Esc, :e; in WordPerfect, WordStar and Word for DOS — three more, matching none of the above. Not a single match. Knowledge of one application didn't transfer to another, and sometimes actively interfered: learning a new application meant unlearning the old one. Being fast in WordPerfect was a mark of belonging to the priesthood — and exactly the same barrier for everyone else. F1 as "help" appeared and disappeared; Esc canceled in some programs, exited in others, repeated the last command in a third. Each program — a separate theology.
The CUA idea was audacious in scale: IBM — a company selling both mainframes and PCs — decided that the interface wasn't the application developer's property but infrastructure. Like a thread standard: doesn't matter who made the bolt — it should fit. Unifying keys — Ctrl+Insert = copy, Shift+Insert = paste, Delete = delete, F10 = menu, F1 = help — let you learn once and live peacefully. Parts of this standard are still alive in Windows, OS/2 descendants, Java Swing/AWT — and, funniest of all, in numerous old terminal systems that keep popping up in banks.
Here's an important nuance that usually gets lost in retellings: CUA was originally written as a standard for keyboard access to GUI. The first goal was to unify not just the mouse but full keyboard navigation in graphical applications: any action available by mouse should be available by keyboard. In this architecture, the mouse is an accelerator for the novice, the keyboard is the main transport for the expert. This is the key thesis around which the entire story revolves: in the canonical 1987 architecture, mouse and keyboard didn't compete — they were layers of one interface: click for learning, keys for speed, F1 for rescue.
To understand what the industry lost, we need to go back another six years — to 1981, to a machine that was twenty years ahead of its time: Xerox Star 8010 Information System, released April 27, 1981 at a price of $16,595 (about $59,000 in 2025 dollars) per machine, and a full basic system with server and laser printer cost $75,000 (over $266,000 today). The first commercial computer with a bitmap display, windows, icons, folders, mouse, Ethernet, file servers, print servers and email — meaning almost everything we use today. A direct descendant of the Alto from Palo Alto, on which Xerox had spent nearly 1000 machines in its own fleet and another 500 in universities by 1979.
And here's a detail forgotten by everyone who retells the myth of "the mouse that beat the command line": in Star, the keyboard wasn't an appendage to the mouse but a system. Wikipedia formulates this dryly but precisely: the user selects an object with a mouse click, then "presses highlighted special keys to invoke standard object functions (open, delete, copy, move) in a uniform manner." Star had physical keys for object operations: AGAIN (repeat last command), OPEN, DELETE, COPY, MOVE, SHOW PROPERTIES. You pressed SHOW PROPERTIES — you saw a property sheet: settings for the selected object (like font size for a character). These aren't "shortcuts" in our understanding. This is a separate keyboard architecture: the mouse selects, keys act. Two hands — two control organs working simultaneously. Sounds suspiciously like what the industry would be moving toward for the next forty years, right?
Star's philosophy was formulated in documentation as "office mimicry": WYSIWYG, icons as office objects, folders, desktop. David Canfield Smith's team believed the computer should look like a desk. (In the same PARC, other storylines were bubbling in parallel — Tesler with his Gypsy, psychologists Card and Moran with their future model; their stories will intersect below.) In this metaphor, keyboard commands had no place: you don't "press" a folder, you drag it. And Star died commercially (discontinued in 1985) not because of the interface — because of price and era: $59,000 for a workstation into a world of IBM PC at $1565. But along with Star, the industry threw out the keyboard architecture too: the next GUI platforms — Macintosh (1984), Windows (1985) — inherited the office metaphor and the mouse, and only individual applications copied Star's keyboard model (Excel with its strange F-keys is the most living example), not platforms.
Worth remembering a date from this same period: September 1984, COMDEX Fall, PCjr: the first public command standard (F1/Esc/F10) in the consumer segment. PCjr ultimately failed, but its keyboard commands survived and grew into CUA. The keyboard turned out to be the most resilient element of a failed product: the product died — the standard lived.
Behind every mouse success in the 1980s stands a man who didn't come to it from the world of graphics — he came from the world of text editors and modes. Larry Tesler, mode skeptic and future Apple vice president, wrote a personal history in 2012 — "A Personal History of Modeless Text Editing and Cut/Copy-Paste" (interactions, July+August 2012) — and it's the best document about how the mouse became "kind." Tesler hated modal interfaces from the 1960s: "modeless" became his obsession, he even had email tesler@nomodes.com (literally "no modes"). In the late 1960s he worked at the Stanford AI Lab, and in December 1968 saw Engelbart's "mother of all demos" live — "mouse, tiled windows, multiple views, outlining, hypertext, collaborative editing, videoconferencing" — and understood where everything was going.
Coming to PARC in 1973, Tesler builds Gypsy — a text editor where he perfects the "mouse selects, keyboard acts" principle: an editor that could be learned in five minutes, no modes — people who'd never touched a computer edited text immediately. Cut/copy-paste and the entire modeless editing philosophy grew from Gypsy, which Xerox editors then passed to Apple Lisa and Macintosh, and through them — to Microsoft Word, Office and Windows. The original multi-paste model, two-step transfer through buffer — all Gypsy experiments.
Important to read Tesler correctly: he didn't "beat the keyboard." He beat modes — states where the same key means different things. His goal wasn't "mouse instead of keyboard" but "no traps for the user." Modeless ≠ mouse-only: Gypsy was a fully keyboard editor that simply had no modal traps. But in the pop version of history, the message is distorted: "modes are evil" became "keyboard is evil." Result: the industry of the next decade fought not modes but the keyboard itself. And it took until 1987 and IBM with CUA to bring the keyboard back into GUI. Hear this rhythm? 1981: Star — mouse-objects + keyboard architecture. 1984: Macintosh — mouse-office. 1987: CUA — keyboard returns. 1995: Windows 95 — keyboard in deep shadow again. 2010: iPad — "keyboard not needed." 2016: Superhuman — "keyboard is back!" 2026: HN-pendulum swung toward keyboard again. Forty years of pendulum, and every time the battles about "keyboard vs mouse" aren't discovery but forgetting the same lesson: mouse and keyboard aren't competitors but layers of one interface.
Why should the keyboard win at all? Not by aesthetics — by mathematics. In 1980, Stuart Card, Thomas Moran and Allen Newell published in Communications of the ACM the keystroke-level model (KLM) — the first rigorous model of interface operation execution time, and in 1983 — the book The Psychology of Human-Computer Interaction, which became an HCI classic. Card and Moran created at PARC the AIP (Applied Information-Processing Psychology Project) group with Newell as consultant — in 1974, long before the model.
The KLM idea: break any task into operators — K (keystroke), P (point mouse to target), H (home hands between devices), M (mental preparation — "think before next action"), D (draw), R (system response) — and sum. The model gave execution time estimates before the interface was built. And — more important — KLM first allowed proof-based comparison of methods: menu vs shortcut, mouse vs keys. The M operator is the most underestimated model element: its heuristics (Rules 0–4 for placing and removing M) formalized what experienced users know by feel: every command is accompanied by a "think" pause, and every extra action adds 1.35 seconds of "thinking." This 1.35 seconds is a number from the original 1980 works: average mental preparation time between physical operations. For a true expert, everything that can be done without M is done without M — ideally the entire routine compresses into a stream of K-operators without a single mental pause.
Apple gives numbers too. The "100ms rule" from the Superhuman blog: any interaction should fit in 100ms — the threshold "where interactions feel instantaneous" — this is Paul Buchheit's formulation, Gmail's creator. Precisely in this spectrum KLM works: a keyboard routine of 3–4 presses is 3–4 × ~0.2 sec + 0–1 M operator; and the mouse version of the same command is P (find target: ~1.1 s per KLM) + H (home hand: 0.4 s) + K + M... The difference between 0.6–0.9 seconds and 1.5–2.5 seconds per action. Multiply by hundreds of actions per day — and you get hours per week. Multiply by 1.35 s for each "think" that keyboard doesn't require — and you'll understand why Superhuman's pitch "every action feels instantaneous" technically coincides with KLM: keyboard kills both P and H and half the M.
And here lives the main ironic twist: GUI never gave cardinal acceleration. In 2005 appeared a paper by David Lane, Albert Napier, Camille Peres and Anikó Sándor from Rice University (International Journal of Human–Computer Interaction, 18(2), 133–144): "Hidden Costs of Graphical User Interfaces: Failure to Make the Transition from Menus and Icon Toolbars to Keyboard Shortcuts" — "Hidden Costs of Graphical Interfaces." The study design is ruthlessly simple: 251 experienced Microsoft Word users, survey — what methods do you use for frequent commands? Results — gut punch: almost no one uses keyboard shortcuts. Even for Cut/Copy/Paste — the only command where shortcuts are popular — the toolbar icon beat Ctrl+X. By strict criteria (shortcuts for more than 60% of commands), shortcuts turned out to be the "favorite method" for only 1.59% of users; by soft — 6.37%. Even Ctrl+C/Ctrl+V were "favorite method" only for 19.12% (soft criterion) and 13.94% (strict). Yet 49.6% of the sample typed faster than 50 words per minute, 92% had more than three years PC experience, 72.9% sat at computer more than 15 hours per week. These people knew shortcuts were faster — Word's menu directly shows shortcuts next to items, toolbar tooltips too. Knew — and didn't do.
The control study (6 participants) confirmed the basic assumption: shortcuts are objectively more efficient than menus and icons. Meaning we're not facing "users didn't know." This is the fundamental shortcut paradox: the interface that teaches (menus, icons) is always more accessible than the interface that's fast (keyboard) — and millions of users get stuck forever on the plateau of "just works." NN/g describes this same effect in a 2024 article about accelerators: all users hit an efficiency plateau — an efficiency plateau after which repetitions don't speed up task execution; accelerators (shortcuts, gestures, voice commands) are needed to break through the plateau — but they must be "easy to discover and easy to ignore." NN/g directly recommends: don't show novices all accelerators at once — they'll be overwhelmed. The asymmetry is fundamental: novices can't tolerate keyboard complexity, experts can't tolerate mouse sluggishness. Any interface is a compromise almost always made in favor of the novice, because the novice is the first impression, the store review, marketing. And so every interface in the world is optimized for day one, not day one thousand.
If 94% of Word users don't want shortcuts — who's writing the 2026 manifestos? Who are these people? An HN comment (top-voted) sets everything straight: "I work with ADA. Put on headphones, turn on the OS voice assistant, put on blinders and run your app or site... without mouse, keyboard only. 1. Democracy is access; make sure everyone has access to your software. 2. Keyboard lets people with disabilities and power users fly through your site/app... but if tab-order breaks — a person with disability hits a wall." Keyboard isn't aesthetics for geeks. It's accessibility as a real scenario, not a checkbox item. In the same thread — classic curb cut factor: ramps are needed by wheelchair users, but used by everyone — with wheelchairs, suitcases, carts. Subtitles — for the deaf, but watched in subway. Keyboard navigation — for the blind — but needed by anyone holding coffee in the right hand.
And proof that "keyboard can be GUI": Bloomberg Terminal — terminal from 1982, $28,000 per year per slot, ~325,000 paying subscribers in 2025, Bloomberg L.P. terminal business revenue — $13.7 billion in 2024. The trader's terminal is a dense, multi-window, keyboard GUI: black screen, function keys, command language "
Superhuman is a pure consumer example: email client built around keyboard and the 100ms rule; one shortcut "Cmd+K" opens command palette — an interface where you type the action and the palette shows the shortcut "for next time." The palette is a teacher: it turns action search into a learning session where each command gradually settles into muscle memory. Superhuman formulates this as a design manifesto: "Users don't need to take their hands away from the keyboard" — users shouldn't have to take hands off keyboard. And importantly — the palette solves the main shortcut disadvantage (they must be memorized): during action search, the palette shows the shortcut — the interface itself turns novice into expert, healing the "shortcut paradox" from Rice. Command palette is now in VS Code (Cmd+Shift+P), Slack (Cmd+K), Linear, Figma, Alfred, Sublime — it's become what CUA was for Windows in the 1990s: a de facto cross-platform standard, just without 328 pages and without IBM.
And last but not least — distributions saved by keyboard: Emmabuntüs — French Debian-based distribution for reusing old PCs through Emmaüs associations, built around keyboard shortcuts for elderly and people with disabilities: full shortcut manual for Orca screen reader, for audio control, for dock navigation in three levels (child/beginner/expert). Keyboard as reuse channel: old PC has weak screen, mouse is inconvenient, but keyboard works — and the distribution is built so a person without mouse can live in the system fully. Keyboard accessibility isn't a "feature," it's architecture.
Now the counterintuitive part, where keyboard doesn't save itself. In May 2026, OSNews published "The text mode lie: why modern TUIs are a nightmare for accessibility" by Thom Holwerda: "There's a persistent misconception among sighted developers: if an application works in terminal, it's accessible by definition." Reality: TUI isn't text but a 2D grid of pseudographics, where each character is a pixel. A screen reader that reads linear CLI stream perfectly (by definition — it's just a log) goes crazy on modern TUI: cursor jumps around the screen with each update, screen reader reads all interface chrome: "hash mark, hash mark, hash mark, dash, dash" — "hash, hash, hash, dash." A person who wanted to read email list hears ASCII table borders.
Compare with native GUI: SwiftUI stores two trees — visual and semantic accessibility tree, and screen reader reads the second. A comment under the OSNews article hits precisely: "Graphical UIs, especially properly made ones, come with nested structure with metadata: 'Here's a window. At bottom a panel with two buttons. Left is Okay with action WM_OK...' This is perfectly readable by screen reader, AI agent or any other computerized agent. And text UI needs full machine visualization — high-level ML and error-prone. Ironic." TUI looks accessible (text, right?), but in reality — worst option: pseudographics without semantics. GUI looks inaccessible (pictures, right?), but in reality — best: every window carries machine-readable description of itself.
This drives the last nail into the coffin of "TUI = accessibility" and simultaneously explains why the 2026 manifesto demands keyboard specifically in GUI: keyboard is important, but keyboard without semantic tree is the same "hash mark, hash mark, hash mark." Keyboard is transport; semantic tree is meaning. Need both layers, and in 2026 both layers finally connected.
And here's the final ironic twist: in 2026 the keyboard got an unexpected ally — AI agents. Modern computer-use agents (Anthropic Computer Use, OpenAI ChatGPT Agent/Operator, Google Project Mariner) struggle with screens designed for mouse. Measurements from fresh reviews: Screenshot-based agents (like Operator) waste tokens and time "looking at" pixels; DOM-native approach with accessibility tree cuts latency per action from 2–5 seconds to under 500ms and cuts token cost by an order of magnitude (numbers from Navya Agarwal, InfoWorld, July 2026). Zylos Research review (February 2026) states: main computer-use agent benchmarks — OSWorld 38% for Operator, WebArena 58%, ScreenSpot 84% for Mariner — all stuck in "how do we make it reliable?" — meaning in the same hole where users got stuck: agent can't reliably "click" a small target.
The solution the industry arrived at is the same as for screen readers: semantic tree. The InfoWorld article is directly titled "Accessibility is the first-class interface for AI agents": "The problem wasn't the agent. The problem is we kept treating the web as a visual surface, when it already has a machine-readable interface — accessibility tree." Plus new WebMCP standard (W3C Web Machine Learning Community Group, 2026): browser exposes to agent typed capabilities directly from markup — and when a field lacks agent annotation, Chrome deduces parameter description from <label> (and if no label — from aria-description). Quote from article: "The same HTML that accessibility required developers to write correctly for thirty years is now the main entry point for contract with agent." And colleague's phrase: "If we'd done accessibility well, we would have gotten this for free".
At OS level — fresh paper (arXiv, June 29, 2026) with self-explanatory title: LUMOS: A Semantic Operating-System Layer for Accessibility-Grounded AI Agents. From abstract: "Operating systems expose interfaces optimized for humans: pixels, icons, windows, visual grouping, mouse movements and keyboard shortcuts. AI agents instead need compact semantic state, grounded actions and reliable feedback." LUMOS converts native accessibility metadata into "semantic blueprints" with roles, names, values and permissible actions. Translating from academic: the interface of the future is not pixels but a graph of objects with actions, and keyboard shortcuts in it are simply human-readable names for operations.
And here's the last irony that must be said aloud. For forty years the industry convinced itself that keyboard is an anachronism and mouse is the future. And in 2026 it turned out: an agent living in your computer is a user without hands, eyes, or mouse. It "presses keys" and "reads semantic tree" — meaning it's exactly a user with disability from the HN comment: "put on blinders and run your app without mouse." An agent is a blind user without pixels and without mouse. And accessibility, which had no budget for twenty years and was always postponed "for later," suddenly turned out to be the interface for a new class of users — and possibly the hottest direction in interfaces in 2026.
One last layer remains without which the picture is incomplete: why people don't change what's inconvenient for them. Classic UIE experiment (Jared Spool, ~2005, published 2011): collected config.ini from several hundred Microsoft Word users, counted who changed settings. Result: under 5% changed anything, 95%+ lived with factory settings. Worse: autosave in that Word version was off by default — and 95% worked without it. Reasons users gave were unerringly common: "Microsoft must know what they're doing." And the truth turned out piquant: autosave was off because a programmer initialized config.ini with zeros — "fast program," and "real defaults" someone will specify later. No one did. The file with zeros went to production — and lived there as "Microsoft settings."
Two morals. First: defaults aren't a setting, they're a decision the industry makes for you. Tog (Bruce Tognazzini, co-founder of Apple Human Interface Group) formulated this harshly: user reads default not as suggestion but as decision experts already made for them. No one changes. And keyboard navigation in GUI lives exactly in this world: if out of box everything works with mouse, 95% will never learn it can be different. Second moral is comic: "defaults" can be not a decision but accident — zeros in config.ini. "Microsoft must know what they are doing" — and in reality one programmer wanted lunch.
This also explains why Rice got 1.59% not 94%: shortcuts in Word have existed for decades, but out of box everything works with mouse — and "latent demand" for keyboard dies at stage "no one touches settings." And so NN/g are right in 2024 when they demand architectural solution: accelerators must be "easily accessible and easily ignorable," gradually revealed (gradual reveal), not "setting for enthusiasts." Superhuman's command palette is the same architecture: it's not a "setting," it's first-class interface, accessible with one Cmd+K from anywhere in app.
Why the 2026 debate is a relapse, not a debate. All arguments already existed: CUA 1987 (keyboard GUI architecture), Star 1981 (mouse selects, keys act), Tesler (modeless, not mouse-only), KLM 1980 (mathematics: keys faster than mouse by 0.6–1.9 s per action). Industry proved everything by 1987, implemented partially, forgot by 1995, rediscovered in 2016 (Superhuman), revolted in 2026 (HN). Forty years of pendulum — because each new interface class (DOS→GUI→web→touch→agents) starts with optimization for novice, and experts with their keyboard always come "after" — and always write manifestos. Nothing new in 2026 manifesto; what's new is who now demands keyboard.
The shortcut paradox isn't solved by training — only by architecture. Rice: 1.59% of experienced users have shortcuts as "favorite method" — while UIE: 95% don't change settings. Waiting for people to "learn" is naive; right strategy is palettes (command palette as first-class interface teaching shortcuts in process of use), gradual reveal of accelerators (NN/g) and keyboard completeness by default (CUA legacy). Mouse — for novice, keyboard — for expert, palette — bridge where novice becomes expert.
"Text = accessible" is the most expensive lie in interfaces. OSNews 2026: modern TUI is a 2D grid of pseudographics where screen reader reads "hash mark, hash mark, hash mark," while native GUI stores semantic tree, read perfectly. Keyboard without semantics is useless; semantics without keyboard is incomplete.
Who's the next big keyboard client: agents. Computer-use agents in 2026 stuck at 38–58% in benchmarks precisely because interface is designed for mouse and pixels. Inversion: agent is a user without hands and eyes; for it "accessibility" (a11y tree, ARIA, semantic roles) isn't option but only road. InfoWorld: switching from screenshots to DOM-native cuts latency from 2–5 s to <500ms and token cost by order of magnitude; LUMOS builds OS-layer from accessibility metadata; WebMCP turns HTML labels into typed contracts for agents. Accessibility, which industry put off "for later" for 20 years, became the fastest-growing interface of 2026 — because it got a new class of users who can't "click with mouse."
And final irony: keyboard, to survive, needed a graphical interface. Not mouse — GUI as semantic structure. Sad fact: keyboard beat mouse in 1981 (Star: mouse selects, keys act), lost to people in 1984 (Macintosh), returned in 1987 (CUA), lost in 1995 (Windows 95), resurrected in 2016 (Superhuman), revolted in 2026 (HN) — and survived only because GUI gave it what it always lacked: names for things. A11y tree + keyboard = interface readable by both people and machines. In this optic, "keyboard manifesto 2026" and "accessibility for agents" are the same program, just with different audience. And this is perhaps the only time in forty years keyboard got an ally without hands.
The 2026 debate:
Historical layer:
5. — Wikipedia: "IBM Common User Access" — CUA 1987, 328 pages, SAA, WordPerfect/Lotus/Word/WordStar/emacs/vi differences, connection to Apple HIG.
6. — Wikipedia: "Xerox Star" — 27.04.1981, $16,595 ($59,000 in 2025), $75,000 basic system, physical keys (AGAIN, OPEN, DELETE, COPY, MOVE, SHOW PROPERTIES), property sheets, WYSIWYG philosophy.
7. — Larry Tesler, "A Personal History of Modeless Text Editing and Cut/Copy-Paste", interactions (ACM), July+August 2012 — Gypsy 1973, "mouse selects, keyboard acts", modeless philosophy, nomodes.com, Engelbart's "mother of all demos".
HCI science:
8. — Wikipedia: "Keystroke-level model" — Card, Moran, Newell 1980 (CACM) / 1983 (book), operators K/P/H/D/M/R, M = 1.35 s, M-placement heuristics (Rules 0–4).
9. — Lane, Napier, Peres, Sándor, "Hidden Costs of Graphical User Interfaces: Failure to Make the Transition from Menus and Icon Toolbars to Keyboard Shortcuts", IJHCI 18(2), 2005 (Rice University) — 251 Word users, 1.59% shortcuts "favorite" (strict), 6.37% (soft), 19.12% for Cut/Copy/Paste, 95% with autosave off.
10. — Nielsen Norman Group, "Accelerators Maximize Efficiency in User Interfaces" (Rachel Krause, Aurora Harley), 18.10.2024 — efficiency plateau, "easy to discover and easy to ignore", gradual reveal.
11. — UIE/Brainsparks, "Do users change their settings?" (Jared Spool) — config.ini experiment: <5% change settings, 95%+ factory, autosave off from zeros in config.ini, "Microsoft must know what they are doing".
12. — Stack Overflow Developer Survey 2025, technology section — VS Code: most used IDE fifth year running; emacs: "Have Used" 0.1%.
Software and keyboard design standards:
13. — Superhuman Blog, "Why Superhuman Mail is built for speed: applying the 100ms rule to email", 28.06.2022 — 100ms rule, Paul Buchheit, latency mathematics.
14. — Superhuman Blog, "How to build a remarkable command palette", 12.10.2021 — Cmd+K, palette anatomy, "users don't need to take their hands away from the keyboard", product list (VS Code, Slack, Linear, Figma, Alfred).
15. — Wikipedia: "Bloomberg Terminal" — December 1982, black interface, ~325,000 subscribers, $13.7B revenue 2024, branded keyboard with yellow keys, command language "
16. — Emmabuntüs, "Emmabuntüs accessibility shortcuts" (Debian Edition 5 manual, Xfce/LXQt) — keyboard shortcuts for Orca, audio, navigation; dock in three levels (child/beginner/expert); distribution for PC reuse through Emmaüs.
17. — GNOME Human Interface Guidelines, keyboard navigation — "just as it should be possible to perform every action with a pointing device, every action should also be possible with the keyboard" (cited in hook source).
Agents and semantics 2026:
18. — Navya Agarwal, "Accessibility is the first-class interface for AI agents", InfoWorld, 07.07.2026 — a11y tree as agent interface, DOM-native: latency 2–5 s → <500ms, order of magnitude on tokens; WebMCP: <label> → typed capabilities; "If we'd done accessibility well, we would have gotten this for free".
19. — Thota et al., "LUMOS: A Semantic Operating-System Layer for Accessibility-Grounded AI Agents", arXiv:2606.30697, 29.06.2026 — semantic OS layer for agents; "humans: pixels, icons, shortcuts; agents: compact semantic state".
20. — Zylos Research, "Computer Use and GUI Agents in 2026: State of the Art", 08.02.2026 — Anthropic Computer Use, Operator/CUA (58% WebArena, 38% OSWorld), Mariner (84% ScreenSpot), "how do we make it reliable?".
21. — W3C Web Machine Learning CG, WebMCP spec (2026) — browser standard typed capabilities for agents (described in InfoWorld).
Contextual:
22. — Wikipedia: "Cut, copy, and paste" — transfer of modeless model to Lisa/Macintosh/Word.
23. — Wikipedia: "Text-based user interface" — TUI definition, CLI/TUI distinction.
24. — Wikipedia: "Human interface guidelines" — Apple HIG tradition 1980s, parallel to CUA.
25. — How-To Geek, "The Origins of Ctrl+C, Ctrl+V, Ctrl+X, and Ctrl+Z Explained" — origin of CUA combinations from PARC era.