Safari + VoiceOver: the "Welcome Guide" modal dialog closes immediately after page load

[afercia]

Describe the bug
When using Safari + VoiceOver the new "Welcome Guide" modal dialog closes immediately after it opens, with no action from the user. This way, the modal dialog can't be used and Safari + VoiceOver users may even be unaware a modal dialog actually opened.

To reproduce
Steps to reproduce the behavior:

• Safari 13.03
• VoiceOver 10
• WordPress trunk
• Gutenberg plugin master at 992a9d4
• make sure to clear your browser local storage to make the Welcome Guide modal dialog open
• with VoiceOver running, use Control Option Right (or Left) arrow to navigate content as users would normally do (worth reminding this is the main navigation mechanism for screen reader users)
• once you're in the admin menu "add new post", press Enter
• the Gutenberg edit page loads
• the Welcome Guide modal opens automatically as expected
• VoiceOver starts reading the page from the beginning: this is the default behavior for all screen readers
• the modal closes (with no action from the user)
• focus is on the document root
• see animated GIF below

Expected behavior

• focus to be moved to the modal dialog
• the modal dialog to stay open

Not sure if this is related to #18537 /Cc @talldan. Seems to me it may be related to timing instead. Can't reproduce with other screen readers on Windows, tested with latest Firefox + NVDA and latest Chrome + JAWS 2019 so seems specific to Safari + VoiceOver.

Regardless, as discussed during latest accessibility team meeting on Slack, making the modal dialog open automatically on page load doesn't seem ideal to start with. Also from a usability perspective, maybe not the best experience. Modal dialogs can be perfectly usable and accessible if well implemented and when they open on user request. Instead, when they open automatically on page load, they're not so different from the annoying (and unexpected) advertising dialogs we're used to bear with on the Internet these days.

[draganescu]

I tested this and it happens only if entering the page via keyboard navigation with VO open and using Control Option Right (or Left) to select the New -> Post links previously.

If say we're on the Dashboard and we use Tab to move to the New -> Post links, even with VO on, the modal will not close.

It appears that VO + the Control Option Right (or Left) leaves and assigns focus on some element behind the modal, making it close.

Will investigate further.

[MarcoZehe]

Yes, VO+Right/LeftArrow changes the focus to focusable elements it traverses. So if the modal opens, but the items behind aren't hidden from accessibility, they can be traversed and receive focus.

[afercia]

Actually, when the modal dialog opens all the body direct children get a aria-hidden="true". We recommended to use this old pattern over aria-modal=true because the latter is still a bit unreliable and doesn't work for old browser / screen reader combinations.

GIven all elements except the modal dialog are hidden from assistive technologies, I'd tend to think this is more a matter of timings.. This modal dialog opens immediately on page load. Which is not only arguable from a user experience perspective but also may trigger some unexpected browser or screen reader behavior.

Opening a modal dialog on page load is really intrusive under many aspects and, at least to me, it doesn't differ so much from the very bad user experience given by advertising dialogs that open automatically on initial page load.

I'd strongly recommend to reconsider this implementation. I do realize the need to provide users with a Welcome guide. However, it should appear on an explicit user action. Instead of a modal that opens automatically, a "Get Started" button displayed at the very beginning of the top toolbar could work. This button could be displayed only on first visit and then disappear when the Welcome Guide is dismissed by users.

I'd tend to think letting users in power of making a choice is always better than taking control of their experience.

[noisysocks]

I'd strongly recommend to reconsider this implementation. I do realize the need to provide users with a Welcome guide. However, it should appear on an explicit user action. Instead of a modal that opens automatically, a "Get Started" button displayed at the very beginning of the top toolbar could work. This button could be displayed only on first visit and then disappear when the Welcome Guide is dismissed by users.

Pinging @kjellr for design thoughts on this.

[kjellr]

I think the button suggestion is worth trying out! The difficulty is finding a prominent place that won't get in the way of the user's actions — the reason we adopted this modal in the first place is that our existing "tips" tooltips were blocking user interaction, but not completely.

There are a number of old ideas that may also be worthwhile to consider still too:

• Consider a dedicated "Help" area of the interface Tips: Consider a dedicated "Help" area of the interface #16464
• Consider adding adding a rotating Tips area to the block sidebar Consider adding a rotating Tips area to the block sidebar  #16594

[afercia]

This still happens in WordPress 5.5 Beta 2 and latest plugin 8.5.1.

[afercia]

Update: To test this it is now necessary to also clear the wp_persisted_preferences user meta from the database, in order to make the various Welcome Guide modal dialogs appear.

I've just retested this issue and I can't reproduce any longer. The Modal dialog component has seen some changes since this issue was created and that may have fixed the issue. Also, it could be that enw versions of Safari and VoiceOver behave a little better.

Tested with:
Safari Version 17.0 (19616.1.27.211.1)
VoiceOver Version 10 (913.3)

Since this issue can't be reproduced any longer, I'm going to close it. Please do feel free to reopen it at any time if you can still reproduce the issue or for any thoughts and feedback,