spectrum-web-components

spectrum-web-components copied to clipboard

Code of conduct

• [X] I agree to follow this project's code of conduct.

Impacted component(s)

sp-menu-item

Description of the requested feature

When menu item is in disabled state , showing user why the menu item is disabled will be useful. Looking for feature like, while using disabled menu item with an info icon or some other icon inside the menu item, and hovering over it to enable tooltip, in that tooltip, reason for the disabled menu item can be shown to user. Currently this feature seems not available. It would be useful if tooltip support in disabled menu item is there.

Mockups or screenshots

No response

Implementation notes or ideas

The above feature worked before, a fix introduced for another bug made this feature unavailable.

First of all, a tooltip in a menu item is almost NEVER accessible, and is likely not the right content model for delivering the capabilities that you are talking about. Menus take a roving tab index approach to keyboard accessibility, which means that the tab stop for the icon would technically be AFTER all of the menu items, not a part of the disabled menu item, or not at all meaning that screen readers would not have access to that content. @jnurthen could tag in on this and correct me if I've misunderstood some of the nuance in delivering this sort of interface.

We're working with the accessibility team to unlock tooltips on disabled content, but current discussions do no include menu items for the reasons listed above. It may be possible to bind a tooltip to the entire disabled menu item after that work, but that is definitely not something that we will be shipping in the near term. Likely Q4 at the earliest.

In that you had previously delivered something that wasn't unaccessible, you can continue to deliver something that is unaccessible via the following code: https://studio.webcomponents.dev/edit/collection/fO75441E1Q5ZlI0e9pgq/FikFeTXNsYhxAVmCz2f4/src/index.ts?branch=disabled-tooltip%40wfVpXdsTYhf9mY2slxW4t2Y2SjC3&p=stories It is not suggested that you deliver content in this way, and it would benefit your product managers to discuss the short comings of this approach with the accessibility team to better devise a path forward with this feature.

Thanks for pointing out the accessibility issue in using tooltip inside disabled menu item.

Have discussed with product manager, since we already delivering the tooltip inside the disabled menu item, will use above fix to make it work so that existing users won’t suffer facing this issue. Once the tooltip support for the disabled menu item you mentioned , becomes available, will be happy to use that.

The unavailable API that has recently been added to Spectrum may be of benefit to this conversation: https://spectrum.adobe.com/page/menu/#Unavailable confirming whether this has made it into Spectrum CSS. Otherwise, there's a good number of changes to make "disabled" but "focusable" content to power these sorts of overlays.

The best path forward will be to use the aria-disabled attribute which is currently outside the scope of options in Spectrum. We would strongly recommend you posit this change to the Spectrum group as a proposal.

Keyboard operability: If using the following users can focus/hover the button in disabled state. The aria-disabled approach will also allow you to have your hover/focus state messaging. We should also take care to observe the content on hover or focus is dismissible, hoverable, and persistent to the WCAG SC 1.4.13 specifications.

Styling: Using aria-disabled will force your team to style the dimmed appearance. You will need to ensure this new pattern works in Windows High Contrast Mode, especially if you’re doing the embedded icon approach as shown below.

Scripting: Using the aria-disabled attribute will also force you to customize the scripting to NOT activate the control. This is something inherent to but not .

Screen reader interaction: Using aria-disabled will tell the screen reader user the control is “dimmed”. This is a great feature because a screen reader user will still be able to perceive the button is in the UI and they will also hear your tooltip.

Contrast: The color contrast of the disabled button is permitted to be lower because it is inactive in the UI. The message that is produced as hover/focus state will need to meet the contrast minimums obviously.

Icon for affordance: This implementation would be great where you add the icon in the button for an affordance to know there is a message there. Since you’ll be tweaking the style in order to use the aria-disabled, you’ll be able to also set that icon’s contrast to a minimum of 3:1 to its background. We do want to point out that this icon is just an SVG image, not button nested inside another button.

General preference and principle: We don’t want to leave this conversation without stating a general preference of the accessibility team… If a message is worth displaying to some user in some cases, then it probably worth showing to all users in all cases. In the example above, that would manifest as having the information about why the case cannot be escalated in plain text, in plain view rather than hiding and exposing based on unique user actions. That is our general preference as a principle of inclusion and not a strict edict you must follow to be in conformance.

As per the latest discussion,

Disabled components are not supposed to be keyboard accessible (and therefore shouldn't have tooltips)? this is why we created the contextual help component (to surface information in a keyboard accessible way and in addition to working in combination with disabled elements, it also works on touch screen devices. Link: https://spectrum.adobe.com/page/contextual-help/

P.S: Contextual Help component is currently being worked upon by the express team as a contribution to our library. RFC: https://github.com/adobe/spectrum-web-components/discussions/4281