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:

Expected behavior
Not sure if this is related to https://github.com/WordPress/gutenberg/issues/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.
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.
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.
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.
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.
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 鈥斅爐he 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:
This still happens in WordPress 5.5 Beta 2 and latest plugin 8.5.1.