fix(status-toggle): use space key to activate radio items

[akashsonune]

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

---

Documentation.
Examples.
Dashboards Demo.
Playwright report.

Coverage Reports:

• charts-ng
• dashboards-ng
• element-ng
• element-translate-ng
• maps-ng
• native-charts-ng

[gemini-code-assist]

Code Review

This pull request adds support for the space key to trigger the selectItem function in the si-status-toggle component. The review correctly identifies that $event.preventDefault() should be called when handling the space key to prevent unintended browser behavior like page scrolling.

[dr-itz]

I think these need to go from tab-activated to arrow left/right. i.e. the active one should have tabindex=0, the others tabindex=-1 and arrow/left (with RTL compensation) should move the focus and active the element.

But. In some use-cases changing the status triggers a potential heavy operation, so an explicit activation with space is probably more desirable but then we also need to wrap the the whole thing into a role=toolbar (i.e. on the host itself)

[akashsonune]

I think these need to go from tab-activated to arrow left/right. i.e. the active one should have tabindex=0, the others tabindex=-1 and arrow/left (with RTL compensation) should move the focus and active the element.

But. In some use-cases changing the status triggers a potential heavy operation, so an explicit activation with space is probably more desirable but then we also need to wrap the the whole thing into a role=toolbar (i.e. on the host itself)

Done. I think it also mentions with the toolbar, the arrow navigation should be move around i.e. from last element to the first and first to last(back arrow)

[akashsonune]

Also I noticed that, selecting the item with mouse click does not focus it. so when we use keyboard later on , the focus is elsewhere while the selection is different. this was also the case earlier with tab navigation

[dr-itz]

The problem I see now is that we get a focus border when operated with the mouse. This shouldn't happen

[akashsonune]

The problem I see now is that we get a focus border when operated with the mouse. This shouldn't happen

@dr-itz That was intentional. As I mentioned above, the focus will be elsewhere , when user tries to use keyboard navigation.
I see similar pattern at other examples- https://carbondesignsystem.com/components/content-switcher/usage/
also https://www.w3.org/WAI/ARIA/apg/patterns/radio/examples/radio/

[dr-itz]

The problem I see now is that we get a focus border when operated with the mouse. This shouldn't happen

@dr-itz That was intentional. As I mentioned above, the focus will be elsewhere , when user tries to use keyboard navigation. I see similar pattern at other examples- https://carbondesignsystem.com/components/content-switcher/usage/ also https://www.w3.org/WAI/ARIA/apg/patterns/radio/examples/radio/

Yes, but the visual focus ring isn't expected when using the mouse. Other controls don't do that

[spike-rabbit]

why not using a proper input with a label? Then a lot bindings are not needed?