carbon: [Bug]: Keyboard Navigation Stuck Within Actionable Notification Component

@kuri-sun the behavior seems unintentionally aggressive. When you render an actionable notification without a close button and turn closeOnEscape to false, focus is trapped indefinitely.

Hello guys. @kuri-sun is right this is an intentional feature that was implemented. But I see the point that @lluisrojass is making by saying that hasFocus=false won’t grab the user focus (as it does now) and also shouldn’t trap the user focus when tabbing.

I’ll bring that issue to the team so we can all discuss together and I’ll came back to you guys as soon as possible.

@kuri-sun

from: https://carbondesignsystem.com/components/notification/usage/#actionable-notifications

Actionable notifications allow for interactive elements within a notification styled like an inline or toast notification. Actionable notifications, since they require user interaction, take focus when triggered and can be highly disruptive to screen readers and keyboard users. With actionable notifications, only one action is allowed per notification. This action frequently takes users to a flow or page related to the message, where they can resolve the notification

from the PR: https://github.com/carbon-design-system/carbon/pull/14877

This enhancement ensures that when a user receives a notification with the hasFocus prop set to true, the focus is correctly directed to the component.

I think when rendered with the default hasFocus=true behavior, the intention is for the notification to hijack focus, and coerce a response from the user. However, a persisted actionable notifications also feels like a valid us case, and plays a different role where it feels this behavior is not appropriate.

@tay1orjones I’ll ping you to discuss, but we need to do some clarification or code changes somewhere. We’ve changed a ton of our InlineNotifications to be Actionable based on the v11 guidance and i’m sure others have done the same. Regardless of that, the current implementation i showed in my screenshot should not act like it does. You can’t even click in the other text fields on the page; it’s not just a tabbing issue. Without some kind of glasspane/modal indication, there’s no way the user would expect that behavior.

@guidari @tay1orjones Can we reopen this issue? I ran into it today and would like to have the history here instead of opening a new issue.
The actionable notification is trapping focus even when used inline, making the other items on the page unusable. Here’s an example below. You can’t click in the text fields or tab to them.

Hey! @lluisrojass

I talked with the team and we are technically already allowing to go off-spec by providing the hasFocus prop to disable the component from taking focus when it’s rendered. The spec says that the focus should be trapped in all cases.

It can be implemented ways for the user to close the ActionableNotification with a close button or ESC key. The recommend action is to set hasFocus to true.

Thank you!

My understanding is that hasFocus=true means grab the user’s focus and trap it until the notification is dismissed or the action is triggered (loops until action taken) and hasFocus=false won’t grab the user’s focus, and in my opinion it should not trap either.

@guidari are you able to provide an opinion?

Hey @ellamathewsonibm and @lluisrojass, thanks for sharing your notes here. Reaching out to Michael Gower about this as well from Carbon’s accessibility team