For displaying shortcuts, we intend to use the OnyxShortcut component right? I'd prefer to remove this example then. Maybe we can update the description at the top to mention that the OnyxShortcut should be used for this?

The downside of using render functions in Storybook is that the generated code snippet in the docs does not reflect the actual code written here. To solve this, we created a createAdvancedStorybookExample() utility function. With it, you can create a dedicated .vue file inside e.g. OnyxKey/examples/CanonicalKeysExample.vue and it will then be rendered as story as well as including the correct source code from the vue file as code snippet

It would be great if we can also support SSR (server side rendering), e.g. with Nuxt. Since detectOperatingSystem would be executed on server side, the output might not match the actual users OS so a hydration mismatch would exist.

To solve this, we could e.g. only call the method in onBeforeMount / onMounted or change the plain function to be a composable instead which handles this under the hood

Can't we reuse the logic from the visual label? :)
Also ideally we use const { t } = injectI18n() to use as translated label

Since we are using <kbd> here, do we even need an dedicated aria label? The browser should already know that its a keyboard shrotcut + its already labeled by its text content (visualLabel)

Since <kbd /> already has the correct semantics for screen readers, and both macOS (VoiceOver) and Windows read the key symbols or text correctly, we don’t need to generate an automatic aria-label.

aria-label should only be used when the user provides a custom label, but we can also remove this completely once we switch to our own key type. I added it only because it was mentioned in the requirements.

https://github.com/SchwarzIT/onyx/issues/2066 icon should be hidden for screenreader, instead key name should be shown (visually hidden)

Would prefer to use a CSS class instead of data attributes :)

Some style adjustments to match whats defined in Figma :) (Basically the font family and font size changed). Also I'd prefer to remove CSS variables that are only used once to keep it simple, what do you think?

I'm not sure about the code styling, but if you think the absence of specific CSS variables that are used once is better.
I'm also for it :)

Just an idea, let me know what you think:

For a great developer experience, it might be nice to type the keyName as a union type that includes all characters so you get e.g. autocompletion / autosuggestion in the IDE and we can unify it a little bit to e.g. not allow "Space", "space", " " etc. for the same key.

it would mean maintainance effort on our side but it might be worth the DX. What do you think?
Incomplete example code:

export type NumericKey = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0;
export type AlphabeticKey =
  | "A"
  | "B"
  | "C"
  | "D"
  | "E"
  | "F"
  | "G"
  | "H"
  | "I"
  | "J"
  | "K"
  | "L"
  | "M"
  | "N"
  | "O"
  | "P"
  | "Q"
  | "R"
  | "S"
  | "T"
  | "U"
  | "V"
  | "W"
  | "X"
  | "Y"
  | "Z";
export type SpecialKey = "ArrowUp" | "ArrowDown" | "...more keys";
export type KeyboardKey = NumericKey | AlphabeticKey | SpecialKey;

export type OnyxKeyProps = {
  key: KeyboardKey;
}

Brilliant idea :)

I was thinking of providing a constant that we would recommend using as a source of truth for keys with the possibility of having some of our own keys and about our own type in the same way as you described as well.

I don't really like the constant, since it's an additional import and an additional variable whose name you always need to keep in mind. So I would avoid using it.

Yes, own type gives a very good DX due to autocomplete, 100% agree.

But support may indeed be an issue. Despite this, in the context of a component like shortcut, this doesn't sound like the end of the world, the most important keys can be declared in the type.

We intended to move the shortcut component to the "Basic" category as its use-case can vary so we found "Basic" the most appropriate one. What do you think?

I simply consider anything that asks the user to take some action as "feedback".
Anyway I would move it simply to "Basic")