Accessibility regression: unspoken first word selection with JAWS screen reader

[elettrona]

Description

WHAT: accessibility bug (regression) in Gutenberg 19.2 - it was not present in 19.1, occurs with JAWS screen reader version 2024.
When writing a new content -post, page, etc.- and having an empty paragraph block, writing some text. Typing is regular, but then, when selecting text, the first word is never spoken and JAWS says "edit box, empty" instead of saying the currently select word; then, selecting further words, they are spoken correctly. Affected also the ctrl+a ("select all") command.
Current result: when editing text, first character/word selected is not spoken by JAWS, while subsequent text is read regularly.
Expected result: every character/word selected, is regularly pronounced by HAWS screen reader.

Step-by-step reproduction instructions

Pre-requirements: Windows 10 or 11, JAWS screen reader 2024 latest build. Browsers, any browser.

1. activate Gutenberg 19.2 plugin
2. create a new content - post, page, it's the same.
3. type a single character, then select it with shift+arrows. JAWS screen reader won't read it. Let's take as a sample, to write the number "1".
4. after the "1", write a "2". Then, select the "2", it won't read it. But it'll then read the "1" typed before, as it'll be the second character selected sequentially.
5. Try the same flow with words. And then, with the "select all" (ctrl+a keystroke) in the single block.

Screenshots, screen recording, code snippet

No response

Environment info

WordPress 6.6.2, Gutenberg plugin 19.2, Windows 10 latest builds and Windows 11 latest build, Chrome and Microsoft Edge latest browser builds. JAWS for Windows 2024 last build. With NVDA screen reader, problems seems not to occur.

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

[afercia]

@ellatrix any recent change in the contenteditable that may cause this issue?

[jeryj]

Potentially caused by #63671 or #64928. I'm going to open some revert PRs so we can test if these might have caused the bug.

[jeryj]

@ellatrix we've identified that #63671 is causing this bug, specifically these lines that set the content editable of the wrapper to true which causes focus to be moved to the body. Removing that contenteditable switch fixes this issue, but breaks the iOS multiselection.

[afercia]

@jeryj thanks for debugging this issue and identifying the root cause.

@youknowriad @ellatrix if it is confirmed that #63671 introduced this regression, I think it would be good to discuss the process and how some changes are introduced in the editor without proper testing. It's not the first time that playing with writingflow, selection or focus introduces important regressions for assistive technologies and I'm not sure playing so lightly with native features is wise, especially without extensive testing. Thanks.

[elettrona]

Gutenberg 19.3 released and the issue is still there. It's honestly impossible to work this way!

[afercia]

@WordPress/gutenberg-core this appears to be a big barrier for screen reader users. I'd kindly ask to consider a fix for the incoming WordPress 6.7 release. Raised the issue priority and added it to the 6.7 editor tasks.