Search & Filter tab/keyboard Selected Count accessibility issues

[pastelcyborg]

Describe the bug

When tabbing through the Search & Filter component, the p-search-and-filter__selected-count element is focused, which is an issue for two reasons:

1. Due to the DOM order, it's focused before the search input, despite being visually after the search input
2. It's focused even when hidden, resulting in "missing" focus when this element is focused

To Reproduce

Steps to reproduce the behavior:

1. Open a Search & Filter demo
2. Tab through the page elements
3. Witness no focused element when hitting tab after the last chip has been focused

Expected behavior

Optimally, the p-search-and-filter__selected-count element should be located after p-search-and-filter__box in the DOM. It should also not be focused when it is visually hidden.

[syncronize-issues-to-jira[bot]]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/WD-14050.

This message was autogenerated

[jmuzina]

Changing the order of elements such that .p-search-and-filter__selected-count comes after .p-search-and-filter__box causes a change in margin left of the filter box, due to a style rule that (as far as I can tell) doesn't come into play under current markup:

This margin left is added:

Due to this style for adding margin left on search box coming just after a chip: https://github.com/canonical/vanilla-framework/blob/4518539cb7f7c94cbb3f90da614274da07d2860c/scss/_patterns_search-and-filter.scss#L140-L142

Removing this left margin keeps the visuals between the last chip and the search box the same. @lyubomir-popov @bartaz is there some reason for this margin left?

[bartaz]

Do we need to change source order? Yes, visually it jumps a bit, but semantically it's quite correct. It informs that there are more chips to reveal. So it kind of makes sense to keep it after chips?

[bartaz]

Closing, not an issue in React implementation.