Enforce DropdownMenu to follow the ARIA menu pattern or add linting to make sure it does

[afercia]

Description

Splitting this out from #67647 (comment)

There have been several cases where extraneous content such as paragraphs with descriptions or other extraneous content have been used inside the ARIA menu rendered by DropdownMenu.

ARIA menus can only contain menuitems (including the menuitemradio and menuitemcheckbox variants), groups and separators. No other content type is allowed within an ARIA menu.

It would be good ot prevent such misusage and breakage of the ARIA pattern by enforcing this constrain via code or, at the very least, by adding some linting rule to prevent extraneous content from being used inside a DropdownMenu.

Step-by-step reproduction instructions

N/A

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[im3dabasia]

Hey @afercia, Thank you for reporting this issue. I have some code ready for this issue, but I have a few doubts.

From what I understand, the issue is that <DropdownMenu> should only have one of the following as direct children:

1. MenuGroup
2. MenuItemsChoice
3. AspectRatioGroup
4. MenuItem

Any other children should be flagged with a warning, as shown in the screenshot below. I wrote a custom ESLint rule, which flagged the following errors. Many of the <DropdownMenu> components were using render props, and most of them had the correct JSX elements. However, I found one case — BlockSwitcherDropdownMenuContents in the following file. How should this case be handled? I was wondering if we could perform a regex check on the JSX element names and allow any that include "menu" or "group." Currently, I’m doing a strict check in my ESLint rule. I suggest this because, in the future, someone might create a custom component to use as a render prop. While the code inside the render prop would be correct, I’m not sure how we’d handle this case.

Additionally, there are three more errors, including incorrect usage of <div> and <Text>, which I was expecting to highlight.

Code for `BlockSwitcherDropdownMenuContents`

gutenberg/packages/block-editor/src/components/block-switcher/index.js

Lines 342 to 350 in dd70c03

	{ ( { onClose } ) => (
	<BlockSwitcherDropdownMenuContents
	onClose={ onClose }
	clientIds={ clientIds }
	hasBlockStyles={ hasBlockStyles }
	canRemove={ canRemove }
	/>
	) }
	</DropdownMenu>

Error snippet after implementing the custom rule:

Let me know what you think about this.

cc: @swissspidy