[Dropdown: Combobox & Multiselect]: Focus state dev implementation

[Kritvi-bhatia17]

Closes #768

The problem

We recently have updated downshift which has resulted in changes to our focus states with the new guidance of 1.2 combo box change.

• Update Dropdown, Combobox and Multi-select (parent's and child's) focus states in the All themes Figma library to reflect these changes for both fixed and fluid styles.
• Add the missing state also

The solution

Ref : Figma branch link

To update:

Dropdown

Default

• In this case, the parent child will not have the focus state when expanded.
  

---

Dropdown - Combobox

Default

• Remove the hover state from the Dropdown - Combo box - Default & Fluid
• The focus stroke or border of the parent state will be 1 px, while the stroke of the child state will be 2 px.
  

Fluid

• Remove the hover state from the Dropdown - Combo box - Default & Fluid
• The focus stroke or border of the parent state will be 1 px, while the stroke of the child state will be 2 px.
  

---

Dropdown - Multi-select

Default

• Add focus and hover state in the Dropdown - Multi-select - Default & Fluid
• The focus stroke or border of the parent state will be 1 px, while the stroke of the child state will be 2 px.
• The focus state for the child will be on the first selected option.
  

Fluid

• Add focus and hover state in the Dropdown - Multi-select - Default & Fluid
• The focus stroke or border of the parent state will be 1 px, while the stroke of the child state will be 2 px.
• The focus state for the child will be on the first selected option.
  

Filterable - Multi-select

• Add focus state in the Dropdown - Multi-select - Default & Fluid
• The focus stroke or border of the parent state will be 1 px, while the stroke of the child state will be 2 px.
• The focus state for the child will be on the first selected option.
  

---

[github-actions]

Thank you for submitting a feature request. Your proposal is open and will soon be triaged by the Carbon team.

If your proposal is accepted and the Carbon team has bandwidth they will take on the issue, or else request you or other volunteers from the community to work on this issue.

[tay1orjones]

@Kritvi-bhatia17 @laurenmrice is this a valid dev issue? We're not sure what the work here would be.

[Kritvi-bhatia17]

@Kritvi-bhatia17 @laurenmrice is this a valid dev issue? We're not sure what the work here would be.

Hi @tay1orjones, so we would be needing to update these changes in storybook as well.

[tay1orjones]

I believe the storybook has most of the changes highlighted in the "after" screenshots. @Kritvi-bhatia17 Could you double check the current storybook and outline the specific changes we need to make in the storybook (styling/stoke changes, etc)?

[Kritvi-bhatia17]

Sure @tay1orjones, will do that!

[Kritvi-bhatia17]

Hi @tay1orjones @tw15egan @sstrubberg @laurenmrice, I've made some updates to the issue and have included tasks under each category of dropdowns.

[Kritvi-bhatia17]

Hi @tw15egan!

As we discussed earlier, I've reached out to @mbgower to clarify a few things. Here are the points and insights I've gathered:

1. The mouse and keyboard interactions regarding the focus state will be consistent. So, whatever is depicted in the updated Figma kit images above will be implemented for both mouse and keyboard interactions.

2. The focus state will remain active even if we move the mouse cursor away from it, as demonstrated in the video.

   

We can further discuss these points over a call to decide on the next steps for this issue, or if there's a need to create a new one.

[mbgower]

Yeah, and to explain the basic rationale here, it's not that removing the focus indicator from Option 1, as a result of mouse movement, is unequivocally WRONG. It's that splitting keyboard and mouse interaction like this is likely to result in issues not that apparent, and so easily compounded.
This is a perfect example; by removing the focus indicator, the focus has also been altered.
To reproduce:

1. Open the dropdown, either with kb or mouse. Focus will be on selected subcomponent
2. Hover over the focused subcomponent, and then move pointer away from the dropdown. DON'T CLICK or in any way put something else in focus.
3. Now press the Down Arrow. Since focus has not been moved, expectation is that Option 2 will receive focus. Instead, the focus goes to the first item in the drop down, in this case Lorem ipsum...

In other words, the visual effect to remove the keyboard focus has actually triggered a REAL change of focus. To a sighted user in this demo situation with a few items, this might seem merely a bit annoying. Imagine I've moved to the 30th position in the dropdown, move my mouse intentionally or unintentionally, and then try to act on the 30th item. My focus has returned to the top of the list. Not only may a user be very confused (especially if they have visual disability), but time on task has obviously taken a huge hit.

Taking the focus indicator off the dropdown item does not inherently mean it has to lose focus, but it increases the likelihood that any issue will not being discovered. Alternatively, leaving the focus on the dropdown item makes it much more likely that until the focus is actually moved somewhere by the user, their point of interaction in the application is going to be maintained.