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.

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"

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.

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.

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.

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.

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.

Which ones, besides web frameworks pretending to be desktop ones? Most if not all frameworks I know support keyboard navigation.

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.

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.

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.

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/...

Sounds like a window manager problem

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.

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.

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.

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

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.

https://www.homerow.app/

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.

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

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

- 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".

You could compromise on not-shipping-before-it's-ready.

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.

https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface...

[1]: https://github.com/philc/vimium/

accessibility work isn't just about making things possible for folks with disabilities, it's about making things better for everyone.

[0] https://en.wikipedia.org/wiki/Curb_cut_effect

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

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 can kinda get that one.

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.

and then 365 came along ... an option to pull stock market data here, a LinkedIn connection there, oh look a wild copilot button appeared.

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.

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.

Can you explain what you mean by this phrase?

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

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.

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.

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.

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.

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).

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.

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.

Devs consistently underestimate how many power users of Excel there are, and often don't understand how they operate.

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.

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.

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 in the accessibility settings.

https://support.apple.com/en-za/guide/mac-help/mchlc06d1059/...

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!!!)

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".

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.

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.

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.

- Spreadsheet-like stuff: arrows, PgDn, PgUp, Home, End, … move inside of it.

A common way this can fail is if the Tab key traverses through the UI elements in an unexpected order.

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.

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.

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

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

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.

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.

That is not a requirement, having access to menus, a master help shortcut ir fuzzy search actions shorcut are other options.

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.

Sorry if that assertion stands opposed to your value prop.

Underlining the accelerator key is subtle and shouldn't be overwelming. Keyboard navigation unaware users probably won't even notice.

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.

[1] I was going to link to a repo, but I just learned that which-key is included in Emacs out of the box.

It's also far less likely to be accidentally typed while trying to fill in a form and fumbling the tab navigation.

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.

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.

> 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.)

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.

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.

To be fair to your point though, that's what most localisation of programs are these days.

https://www.augenbit.de/wiki/images/5/57/Arbeitsplatz.png

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.