Create accessible dropdown component

[rak-phillip]

Summary

This creates a new dropdown menu component that can be used to create accessible dropdown menus with built-in keyboard navigation.

Fixes #12771
Fixes #12772
Fixes #12790

Occurred changes and/or fixed issues

• Add new RcDropdown components to Rancher Components
  • RcDropdown.vue - Root dropdown component that controls dropdown communication and behavior. Dropdowns are composed of Triggers, Items, and Separators
  • RcDropdownItem.vue
  • RcDropdownSeparator.vue
  • RcDropdownTrigger.vue
• Add new RcButton component to Rancher Components
• Replace Page Action Menu and User Menu with new Dropdown Menu components
• Update unit tests

Technical notes summary

RcDropdown consists of several, tightly-coupled, composable components that are designed to be accessible and provide keyboard navigation out of the box. My primary motivation for promoting component composition over a props-driven approach was to allow for replacing multiple bespoke dropdown menu implementations without requiring too much refactoring in the process. The two dropdown menus that are replaced in this PR demonstrates this ability by showing how RcDropdown can be used to replace the native html element without requiring much effort with regards to considering component logic or keyboard navigation.

Areas or cases that should be tested

• Page Actions Menu
• User Menu

Areas which could experience regressions

• Page Actions Menu
• User Menu

Screenshot/Video

dropdown-demo.mp4

Checklist

• The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
• The PR has a Milestone
• The PR template has been filled out
• The PR has been self reviewed
• The PR has a reviewer assigned
• The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
• The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes

[aalves08]

General comment:

Kind of hard to read for me since I am not familiar with the composition API. Maybe you can guide me today through the PR on our sync and tutor me on some of the composition API aspects.

If I am not mistaken on my analysis (bear with me):

• why is RcDropdownCollection needed instead of just using RcDropdown? seems to be a div with some props
• why does RcDropdownItem registers event handlers for keydown for each individual item? If we have 15 items, we are registering 15x2=30 events. Can't that be achieved in a broader level with only 2 event handlers in a component like RcDropdown?
• we should have some props on RcDropdown to control certain props of the v-dropdown, if needed. We can add those later as per need basis. Same for the other components like aria-label in the RcDropdownCollection, if we are going to keep it.

Nevertheless, the functional seems to be exactly what was needed and behaves well. Just some minor adjustments needed on focus:visible, especially on dark mode where the white border and outlines overlap in a weird way, imo.

[richard-cox]

• Generally
  • Compared to options api, composition api can get really confusing given the amount of types and consts that are glued together at different points. In more complex components this could lead to a lot of confusion. Is there any way we can clean these up to be more clear? I’ve made some comments but overall i feel we’re missing something.
• Testing
  • Has this been tested (even in a hacky way) with SSO enabled?
• UX
  • When the hover state of the action menu is visible and then it gains the focus state the box grows in side (gains the border). This feels a bit off putting. Can the focus be included with the hover and be a different colour? Need to discuss with UX team?
  • Focus state of user avatar (border not flush with button content) is different from focus state of header action menu (border flush with button content
• Bugs
  • After clicking on the action menu the drop down is shown. Pressing tab though doesn’t take focus to the first entry in the drop down. Same issue for user avatar (first entry not selected)

Update
Missed two bugs

Dropdown location doesn't seem correct. Chrome Version 132.0.6834.83 (Official Build) (64-bit)

[rak-phillip]

• Generally
  - Compared to options api, composition api can get really confusing given the amount of types and consts that are glued together at different points. In more complex components this could lead to a lot of confusion. Is there any way we can clean these up to be more clear? I’ve made some comments but overall i feel we’re missing something.

I’m working on organization techniques. I still think some of these patterns can be improved upon.

• Testing
  - Has this been tested (even in a hacky way) with SSO enabled?

That’s a good callout - SSO will need to be tested. I can deploy these changes and report any modification required when using github auth.

• UX
  - When the hover state of the action menu is visible and then it gains the focus state the box grows in side (gains the border). This feels a bit off putting. Can the focus be included with the hover and be a different colour? Need to discuss with UX team?
  - Focus state of user avatar (border not flush with button content) is different from focus state of header action menu (border flush with button content

This is how the menus behave today:

We are actively engaging @edenhernandez-suse to develop consistent designs and patterns for dropdown menus throughout Dashboard. rancher/ux#113

• Bugs
  - After clicking on the action menu the drop down is shown. Pressing tab though doesn’t take focus to the first entry in the drop down. Same issue for user avatar (first entry not selected)

This is not a bug and is by design. The design guidlines for the menu pattern, provided by w3, detail specific usage of arrow keys and tab behavior.

https://www.w3.org/WAI/ARIA/apg/patterns/menubar/

[rak-phillip]

Dropdown location doesn't seem correct. Chrome Version 132.0.6834.83 (Official Build) (64-bit)

The placement has been updated

[aalves08]

Codewise, there's a lot to take in, but you've addressed my main concerns after the first review + we've been discussing details in our weekly syncs on accessibility, so I would say that on that front Richard has presented a very thorough review which seems to be enough to act on.

Functionality wise, I would say it meets all of the demands of the default behaviour expected to this type of element. I did manual tests on both elements you've replaced on the header component and they LGTM.

One last question: do you think we need aria-label's in the dropdown trigger and dropdown item? 🤔

[rak-phillip]

One last question: do you think we need aria-label's in the dropdown trigger and dropdown item? 🤔

Agreed. I made the change.