fix(aria/menu): accept a bare disabled attribute on MenuItem

[DuncanFaulkner]

MenuItem.disabled was declared as input<boolean>(false), so <div ngMenuItem disabled> failed strict template type-checking (and was not disabled in JIT). It now uses booleanAttribute, like the disabled inputs on the other aria directives.

Adds a test that a bare disabled attribute sets aria-disabled="true".

Fixes #33964

[crisbeto]

Looks like CI is failing.

[DuncanFaulkner]

@crisbeto all fixed

[ok7sai]

This might introduce side effect in some cases. Currently Aria menu items only supports soft-disabled by only setting aria-disabled, but if we allow using boolean attribute disabled, then for elements like <button>, it gets hard-disabled when disabled is applied.

I haven't tested but I think this affects the list-navigation behavior. If a button menu item has set disabled, but internally it's soft-disabled to the list, then I am not sure 1) if the navigation can still puts focus on the disabled menu item, or 2) the focus falls back to the <body> because the menu item can't be focused, and 3) how screen reader reads the result.

[crisbeto]

The way we deal with this on Material components that support coercion for disabled is to have an attr.disabled host binding. It doesn't seem like we have that for Aria though.

[ok7sai]

The way we deal with this on Material components that support coercion for disabled is to have an attr.disabled host binding. It doesn't seem like we have that for Aria though.

We have in some places like Aria accordion trigger, because it's commonly applied to <button>. Not for the Aria menu item because we assumed soft-disabled is preferred.

Adding [attr.disabled]: 'null' (if want to keep the menu items to always be soft-disabled) would solve that if we don't need to support hard-disabling. Looking at the linked bug I think that's good enough.