WordPress
Playground block: Dismissing exit-editor-with-keyboard tip should trigger a spoken announcement
When the user dismisses the exit-editor-with-keyboard tip, there should be a spoken announcement.
This is a follow up for PR #340 where there were difficulties getting the announcement to be spoken in a timely manner. See https://github.com/WordPress/playground-tools/pull/340#issuecomment-2259309390
Quoting from this comment:
@joedolson when the notice is dismissed, I am moving the focus to the code editor so the focus is not lost. Is it right to say we need this kind of focus management when removing an element that was previously focused? Changing focus to the editor seemed like a meaningful focus transition since the user is acknowledging how to exit the editor.
If focusing the editor on dismissal is the right course, what I am finding is that the focus change interferes with the spoken announcement. In my testing, if the focus change is made in response to dismissing the exit-editor notice, VoiceOver does not speak an assertive message. It will speak a polite message but only after reading what appears to be the entire content of the editor, making the message untimely.
Do you have any suggestions about how we could address this?
The fact that the entire editor text seems to be read on focus is one problem. The focus change to the editor seems to interrupt an assertive message, and if we use a polite message, we may wait a very long time for the editor contents to be read before a spoken notice of banner dismissal.
As a compromise, I wonder if we can set the focus to the active file tab instead. Then, even if we have to wait for it to be read, the spoken message will at least be timelier than a notice read after all editor contents.
@joedolson, when the notice is dismissed and removed from the DOM, we move the focus to the code editor so focus is not lost but rather moved to a relevant place following the dismissal. Unfortunately, the fact that we move focus to the editor causes VoiceOver to read the contents of the editor (which can be substantial) before reading a polite notice that the notice has been dismissed. If we make the spoken notice assertive, the change in focus seems to completely skip the reading of the assertive notice.
Perhaps other screen readers perform better in this case.
Regardless, I've tried various approaches that would change the order and timing of the the focus and the speaking but haven't been able to figure out a good way to get have dismissal spoken by VoiceOver in a timely matter.
Do you have any suggestions? It seems like the need to speak and the need to transfer focus are at odds with one another.
The notice itself says "Click to dismiss". Does that make this circumstance any more tolerable if we cannot effectively speak the dismissal?
First, the dismissal message can be very short, e.g. 'Notice dismissed'.
When moving focus, it is best to move focus to something more concise; the editor itself contains a potentially large quantity of content, so it's not a great place to focus. If the buttons used a tabpanel structure, I'd be pretty comfortable moving the focus to the active file button; can you change this interface to use tabs? (I know you called it a tab; and they are designed to look like tabs, but they are not using a tabpanel structure.)
Otherwise, I'd want to move focus to the immediately previous focusable object (the download button). This is because moving focus to the immediately preceding object should make the user's position clear to them: by jumping to an object that they've already located in the DOM, their position is communicated clearly.
Here's an article about this: https://adrianroselli.com/2023/08/where-to-put-focus-when-deleting-a-thing.html
The TL;DR on that is "move to the prior equivalent control or its grouping container". E.g., the previous button (the download button), or the container it's in. Which, if this was a tabpanel, would be the start of the tabpanel, effectively giving focus to the first tab.
It's not particularly critical that the dismiss action is the next thing announced; if the focused object is read first, and then the dismiss notice is announced, that's fine. But obviously that's more of a problem if the focused object is very complex or long.
Thank you, @joedolson. I went ahead and made the quick fix (#348) to focus the download button and speak a polite "Notice dismissed" message afterward.
It seems like it would be better to convert to a tabpanel structure because it communicates more to those using assistive technologies. Is that right? If so, I can file an issue for that.
I appreciate the link to "Where to Put Focus When Deleting a Thing". It was helpful.