The "access key" feature means recognizing & in the title option and interpreting that as an access key: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/menus/create#title

To reduce confusion it may make sense to move it under the title key in the schema data.

In general the BCD can list features that aren't API properties but references to special behavior. There are no established patterns for documenting that.

I offer to work on this, which will probably help me to get a deeper understanding of this matter.

If I am allowed to contribute, may I:

1. Fix the notation of the properties in the same patch?
2. Use the nested notation as seen here?

What do you mean by fixing the notation of the properties?

Previously I wrote "To reduce confusion it may make sense to move it under the title key in the schema data.", under the assumption that the "title" property was already listed in the BCD. Since it is not there, there is no separate "title" entry in the BCD and suggesting to move it there is not very meaningful.

The BCD already lists a separate description,

... so the "accessKey" property name does not appear anywhere. Renaming it to something else doesn't add much value at this point.

2. Use the nested notation as seen here?

That was what I was thinking. In this specific case, it is not rendered in the BCD because the intermediate entry is missing the __compat key. I wish that we handled that better... At the least we could render items with compat data, and omit the compat info from intermediate rows (to signal that the compat is unknown).
And it would be nice if we have a unified convention for declaring methods vs properties/parameters (or marking something as a top-level method). Once we have that we could update the {{Compat}} macro to render the BCD with the right name (instead of the current practice which joins the key names together with a dot as separator).

My idea was to use the suggested notation for properties here, and thus do the following renaming:

• command -> createProperties_command_parameter
• icons -> createProperties_icons_parameter
• visible -> createProperties_visible_parameter

I then would add the missing createProperties_title_parameter entry and move the accessKey to become a child of createProperties_title_parameter

My alternative suggestion would be to not use the <paramName>_<propName>_parameter notation, but instead create a new createProperties entry and move all the listed properties as children (without any special name convention), as it is done here. I would then propose to officially add that notation as a suggested notation of properties as well.

The currently used notation makes it difficult for clients to work with BCD, there is no indication that command, icons and visible are properties of the createProperties parameter. The client can check for different notations, but that makes everything very difficult.

Might it be best to open an issue about establishing a for documenting browser-specific support for the interpretation of specific fields in objects and documenting that pattern in the BCD Data guidelines?