Page MenuHomePhabricator

MenuButton: make the API consistent internally and with other Codex components
Closed, ResolvedPublic

Description

Background

The current API of the menu component has a couple of issues:

  1. It's currently possible/required to provide both an aria-label and a visible label for MenuButtons that have a visible label. This is redundant and could be confusing for users of assistive technology.
  2. If you want to have the default icon and text, you have to override the default slot, meaning you have to re-implement the default icon yourself. This could be confusing since the default icon works for an icon-only button, but not icon + text
  3. The API for this component is different than that of Button and ToggleButton, where visible button content is provided via the default slot, an aria-label is provided for icon-only buttons, and there is no default icon.

Proposed solution

To make the experience of adding a label consistent with the existing Button and ToggleButton components, the DST engineers propose the following API:

  • Visible ToggleButton content must be passed in via the default slot. There would be no default content of this slot.
  • We use the same system we use in Button and ToggleButton to detect if the button is icon-only and throw a warning if it is and there is no aria-label

This would mean the following changes to the existing code:

  • Remove the toggleButtonlabel prop
  • Remove the default slot content
  • Make sure an aria-label applied to the MenuButton component gets passed to its internal ToggleButton component. We could either add a prop called ariaLabel, or use the useSplitAttributes composable to pass all attributes to the internal <cdx-toggle-button> component.
  • Implement the useIconOnlyButton composable, like in the Button and ToggleButton components

We would also need to update the demo page accordingly.

Implications

Pros:

  • Simpler API
  • No more redundant aria-label and visible label
  • Consistent with Button and ToggleButton

Cons:

  • No more default icon (ellipsis)
  • We wouldn't be enforcing an aria-label on the icon-only version of MenuButton, just warning about it

Acceptance criteria

  • Validate this proposal with design
  • Implement the changes in MenuButton
  • Update the component docs and demos

Event Timeline

@bmartinezcalvo, we're proposing some changes to the MenuButton component for improved accessibility and consistency with other components. These changes would have one impact we wanted to talk to you about: it would remove the default ellipsis icon. instead, users would have to pass in the icon they want to use, just like with a regular Button or ToggleButton component.

Is this acceptable? We saw the ellipsis icon being used throughout the MenuButton spec, but weren't sure if it was a necessary default on the engineering side. I read through the component guidelines on MenuButton, and it doesn't seem like the ellipsis is meant to be a default, but we wanted to double check with you.

El T366538#9857240, @AnneT escribió:

@bmartinezcalvo, we're proposing some changes to the MenuButton component for improved accessibility and consistency with other components. These changes would have one impact we wanted to talk to you about: it would remove the default ellipsis icon. instead, users would have to pass in the icon they want to use, just like with a regular Button or ToggleButton component.

Is this acceptable? We saw the ellipsis icon being used throughout the MenuButton spec, but weren't sure if it was a necessary default on the engineering side. I read through the component guidelines on MenuButton, and it doesn't seem like the ellipsis is meant to be a default, but we wanted to double check with you.

@AnneT posting here the same response as in our intern conversation. I'm ok with removing the ellipsis icon as the default icon since, as illustrated in the Best practices section, the button could use any icon or type of button (icon-only, text-only, or icon with text). I used the ellipsis icon to illustrate that this icon will be one of the most used since the MenuButton displays more actions or options. For this reason, we can implement the button without a default icon but I would illustrate the MenuButton guidelines using the ellipsis icon in many of the cases.

Change #1039270 had a related patch set uploaded (by LWatson; author: LWatson):

[design/codex@main] MenuButton: refactor the API for consistency

https://gerrit.wikimedia.org/r/1039270

Change #1039270 merged by jenkins-bot:

[design/codex@main] MenuButton: refactor the API for consistency

https://gerrit.wikimedia.org/r/1039270

@lwatson I'm reviewing the latest updates in the MenuButton demos. Sharing some minor details for improvement:

  1. Let's use "More options" as the base text in the Configurable demo to align with the examples in the Guidelines. Additionally, this MenuButton will display more options or actions.
  2. Menu items with icons and scroll:
    • Since the previous demo is "Menu items with icons", I would rename this one to simply "Menu with scroll" and I would remove the icons for clarity.
    • Although the number of visible items can be customized, I would avoid using the scroll with less than 5-6 visible menu items. So I would include more visible menu items in this demo. In case you need an example with more menu items, you can use this one
      Captura de pantalla 2024-06-06 a las 13.09.01.png (590×1 px, 62 KB)

@bmartinezcalvo thanks for the design feedback! I can open a patch to update the MenuButton demos as you suggested and include this example with a long menu list. This cleanup patch (preview) changes the demo heading name from "Menu items with icons and scroll" to "With configurable scroll". Does this heading sound good?

El T366538#9867410, @lwatson escribió:

@bmartinezcalvo thanks for the design feedback! I can open a patch to update the MenuButton demos as you suggested and include this example with a long menu list. This cleanup patch (preview) changes the demo heading name from "Menu items with icons and scroll" to "With configurable scroll". Does this heading sound good?

@lwatson It looks good. I would instead rename it to "Menu with configurable scroll" since the scroll is not included within the button but within the menu. But the other option sounds good as well.

lwatson changed the task status from Open to In Progress.Jun 6 2024, 6:57 PM
lwatson updated the task description. (Show Details)

Change #1041776 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] Update Codex from v1.6.1 to v1.7.0

https://gerrit.wikimedia.org/r/1041776

Change #1041776 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.6.1 to v1.7.0

https://gerrit.wikimedia.org/r/1041776