From Elizabeth's accessibilty analysis

How can a user use any of the quick buttons in a message row using a keyboard (star, read, spam)?

Alex:

We need to make the "more" button keyboard accessible and expose those shortcuts in the context menu

Making header buttons (including More v button) keyboard accessible is Bug 1816784.

Exposing shortcuts in context where they are helpful to boost efficiency

Main menu is hidden by default hence exclusively exposing keyboard shortcuts there is pretty hard to discover. It also makes no sense having to dig into the main menu and look for shortcuts. Shortcuts should be shown in the context where they can help users to use Thunderbird more efficiently. See bug 1647654 for a good example and some related discussion. However, minimalists, mouse-only users or advanced users who already know all the shortcuts may not like their context menus being filled up with all those shortcut labels. So imho this would call for a global pref for showing shortcuts on context menu, defaulting to TRUE.

Also note related Bug 1383627 - Display keyboard shortcuts in tooltip - perhaps that should have a global pref, too.

Main menu is hidden by default

Well, that's a big problem frankly :/

Anyway, I don't think context menus should show shortcuts. There's really a need to keep context menus short, and pretty.
If you want to make them known, it could be better to have have an easy way to show the available shortcuts as some kind of of page/overlay.

(In reply to Magnus Melin [:mkmelin] from comment #2)

Main menu is hidden by default

Well, that's a big problem frankly :/

I tend to agree.

Anyway, I don't think context menus should show shortcuts. There's really a need to keep context menus short, and pretty.

That's your personal preference, and I'm suggesting here that you can still have it your way and switch shortcuts in context menus off, but for new users, we may want to expose them more aggressively.

I cannot imagine a more suitable place for exposing shortcuts than directly in the context where they can be used to improve your workflow. After going a couple of times through that context menu, you may figure that using the shortcut may serve you better. Imo we want to proactively educate users about this because ux-efficiency is part of TB's brand core, so the more users learn to appreciate the ux-efficiency of using the shortcuts, the more they may bond with our product.

If you want to make them known, it could be better to have have an easy way to show the available shortcuts as some kind of of page/overlay.

Can you elaborate? How do users trigger the page/overlay? How would it look? Which shortcuts should be displayed?
I still doubt anything could be as easily discoverable as having the shortcuts directly in the context menu.

(In reply to Magnus Melin [:mkmelin] from comment #2)

Main menu is hidden by default

Well, that's a big problem frankly :/

Not a problem since it's a pref away and we're working hard to make actions contextually discoverable and keyboard accessible.

Anyway, I don't think context menus should show shortcuts. There's really a need to keep context menus short, and pretty.

This statement is incorrect and just a personal preference.
There's no benefit nor good actionable item here.
Context menu should be useful, accessible, and expose important shortcuts to users.

If you want to make them known, it could be better to have have an easy way to show the available shortcuts as some kind of of page/overlay.

A global shortcut overlay is something useful for exposing primary actions, like navigation for the primary tabs, or global actions like triggering compose window, and so on.
Adding all the shortcuts into a single section that it's outside the context of the action the user is currently doing adds a lot of cognitive burden in learning those shortcuts. Not a great solution for specific actions.