(Accessibility) [DESIGN]: Session timeout `toast` message would benefit from receiving focus on first render

[1Copenut]

UPDATE Per conversation in comments below ( https://github.com/elastic/kibana/issues/138333#issuecomment-1487021187 ) we're opting to make this a modal instead of extending EuiToast to manage focus for session management.

Steps to reproduce

1. Open the dashboard in chrome browser
2. Leave the window inactive for certain period.
3. Notice the appearance of the toast message warning user will be signed out.
4. Verify the toast message can receive keyboard focus, but it takes N+ number of TAB keypresses to do so.

Actual Result

• Toast message appears on screen and can take keyboard focus, but is not focused on first appearance.

Expected Result

• Test the benefit of having the toast message receive keyboard focus on first appearance, so it's more immediately actionable for keyboard and screen reader users.

Kibana Version: 8.4.0

OS: MacOS

Browser: Safari

Screen reader: [if relevant] VoiceOver

Relevant WCAG Criteria: SC 2.2.1: Timing Adjustable - Level A

[elasticmachine]

Pinging @elastic/kibana-accessibility (Project:Accessibility)

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[legrego]

Thanks for writing this up, @1Copenut.

Your description above is great, but I want to clarify: we only want the session idle timeout toast to receive focus, correct? What about the toast message that warns of an upcoming session expiration which doesn't allow the user to extend it by clicking the button:

If you only want the toast mentioned in your description to receive focus, then I'm mostly open to that approach. This would only happen in the event of user inactivity, so it wouldn't interrupt a user's workflow.

If, on the other hand, you want both session-related toast messages to receive focus, then I worry about interrupting critical user workflows.

@elastic/kibana-design / @elastic/platform-design: sorry for pinging you both, I wasn't sure which team would be most appropriate. Do you have any thoughts or suggestions for this?

I'm also not married to using toasts for these notifications, but that's probably a different discussion 🙂

[1Copenut]

@legrego Great question! I wasn't aware of the status-only toast message. I'll answer your original question first, and follow on with another.

Yes, if we're exploring setting focus, it would only be for the toast message that has a button to extend the logout. Setting focus on a read-only message--that screen readers will announce anyway--feels unnecessary.

What is the use case for a session timeout message that doesn't have a button to extend the session? I'm asking without context, and am concerned this message by itself doesn't meet the SC 2.2.1 Timing Adjustable threshold. It doesn't have an action like a button to reset session, and doesn't provide any instruction like scrolling, pressing a key, etc. to prevent log out.

Improving this non-button toast message could be as simple as adding a sentence on what to do. I don't want to be prescriptive, just give options the wider team can riff on and select the best solution from.

[legrego]

Yes, if we're exploring setting focus, it would only be for the toast message that has a button to extend the logout. Setting focus on a read-only message--that screen readers will announce anyway--feels unnecessary.

👍 perfect.

What is the use case for a session timeout message that doesn't have a button to extend the session?

This is related to our discussion here: https://github.com/elastic/kibana/issues/136154#issuecomment-1187266271. In a nutshell, this is a security feature that an Elastic administrator can configure, which forces their users to reauthenticate after a custom time period. One use case is to make sure that we respect changing privileges in a third-party system. For example, if I login to Kibana via an Okta integration, then Okta will tell Kibana what my privileges should be, based on my organization's policies. If they revoke my privileges in Okta, then my Kibana session will continue to function as it did before, until we force them to reauthenticate.

Improving this non-button toast message could be as simple as adding a sentence on what to do. I don't want to be prescriptive, just give options the wider team can riff on and select the best solution from.

I'm definitely open to improving the messaging here if it's unclear. There isn't much a user can do, aside from saving any unfinished work before we forcefully end their session. Maybe adding something to that effect would be enough?

[MichaelMarcialis]

@elastic/kibana-design / @elastic/platform-design: sorry for pinging you both, I wasn't sure which team would be most appropriate. Do you have any thoughts or suggestions for this?

This approach makes sense to me (i.e. give toast with "Stay logged in" button focus, but not the toast without the button).

[legrego]

Thanks, @MichaelMarcialis!

[1Copenut]

@legrego Thank you for the link back and recap on the session timeout vs. idle timeout. I didn't catch the difference the first time around but am clear now.

I think advising users their session is ending, save any unsaved work, and reauthenticate makes for a clear, actionable message. We're all in agreement this session timeout (without a button) should not receive keyboard focus, just announce itself to screen readers on first appearance.

I appreciate the thorough discussion. This helps me understand the problem space and provides a good record of decisions.

[legrego]

@1Copenut

I think advising users their session is ending, save any unsaved work, and reauthenticate makes for a clear, actionable message. We're all in agreement this session timeout (without a button) should not receive keyboard focus, just announce itself to screen readers on first appearance.

Excellent, I think this is something we can move forward with.

I appreciate the thorough discussion. This helps me understand the problem space and provides a good record of decisions.

Same, thank you for taking the time to work through this with us!

[thomheymann]

Blocked on EUI to extend the EuiToast component to allow for setting focus

[thomheymann]

@1Copenut / @MichaelMarcialis Would it make more sense to change the toast into a modal window if we want it to take over focus? Toasts are designed for background notifications that don't interrupt the user's work. If we want to change that to fix the accessibility issue described maybe a toasts isn't the right component for this type of prompt anymore?

[1Copenut]

UPDATE: Confirmed, a modal will be the right approach here. It captures user attention, has the a11y helpers built in, and manages focus so action can be taken promptly.

@thomheymann This does sound like a better approach, yes. I'm taking it to the EUI team meeting today (28 March) for a quick confirmation. I'll update my comment here after.

[thomheymann]

Brilliant, thanks for confirming!