JAWS (screen reader) doesn't read out the editable areas content

[afercia]

We're getting reports from accessibility testers that the content of the paragraphs etc. is not read out by JAWS or that weird things happen.

I've tested on Windows 10, IE11, and JAWS 2018 and was able to reproduce following a specific flow. Please try to follow the steps below to reproduce. See also the videorecording:
https://cloudup.com/cGohxttOPhN

In the first part of the video I'm moving through paragraphs using the Tab key and then:

• use left and right arrow keys to read by character
• use Ctrl + left and right arrow keys to read by word

JAWS reads out just "blank" or nothing.

Instead, in the second part of the video I'm moving through the paragraphs using the up/down arrow keys and JAWS reads the content by character and by word as expected.

Seems a pretty weird behavior and I have no idea why it's happening.

I guess we should investigate what changes in the blocks when moving via Tab or arrow keys. Any JS event triggering some behavior? Any attributes change? Any CSS change? (yes also CSS could play a role).

Any help from who knows the editable area internals would be greatly appreciated. /cc @aduth @youknowriad @iseulde

[aduth]

For context, does JAWS tend to work generally well with a plain contenteditable element ?

[afercia]

As far as I can tell JAWS works well with contenteditable. In this codepen: https://codepen.io/afercia/full/LdJgdK/ I've tested it a bit, including some complex HTML copied from WP and JAWS always reads out the content of the contenteditable element. So I'd tend to think it's not something related to HTML.

[afercia]

To further clarify this issue, I'd recommend to have a look at the testing session by @sinabahram recorded by @joedolson at CSUN 2018, starting from minute 2:26 https://youtu.be/qpzyiL7n__0?t=2m26s and also published on https://make.wordpress.org/accessibility/2018/03/28/accessibility-of-gutenberg-the-state-of-play/

@sinabahram I'd greatly appreciate any help here, when you have a chance! Since you've tested at CSUN, the editable fields in the post content have been updated to use an ARIA role "textbox". For example the paragraph "block" should now be announced as edit text. Still to improve:

• the labels (please ignore them for now)
• aria-multiline should be set to true

However, JAWS still doesn't read the field value, or it does in a very inconsistent way.
Please also consider these editable fields are not real form fields. For example, a paragraph is a "p" element with a contenteditable attribute. This shouldn't make a difference, as the role textbox maps it to an edit text field. But still, there's something going on that prevents JAWS to correctly read the value.

[afercia]

Testing a bit more with IE 11 and JAWS, I've noticed there's something related to focus, to reproduce:

• tab into an existing paragraph
• be sure JAWS switched to forms mode
• try to read the paragraph content by character or by word
• JAWS read out "blank"
• now, press Alt + Tab to switch to any other application window that's currently opened (open one before the test if necessary)
• press Alt + Tab to switch back to IE11
• the caret should be in the same place as before, and now JAWS reads out everything correctly

[sinabahram]

That is because you are most likely reading things now with the virtual cursor instead of the PC cursor e.g. you returned to browse mode upon alt+tab, but I’m happy to help debug. Does it behave correctly in Chrome/Firefox?

[afercia]

Yep works correctly in Chrome/Firefox, seems it's just an IE11 thing. Aside: one more reason why you don't hear the input value announced when you tab into it, is because the text within the field doesn't get selected. All browsers natively select the text within text fields. Instead, the Gutenberg fields behave more like textareas.

[tofumatt]

Is this also a problem in Edge or just in IE11? We definitely support IE 11 but doesn't Windows 10 ship with Edge these days anyway? I know users can opt to use IE, but I just want to know the size of users affected.

We tend to prioritise IE 11 fixes a bit less, in general.

[afercia]

To my knowledge Edge doesn't work so well with JAWS and with other screen readers. Works a bit better with Narrator. You may want to have a look at these data about Screen Reader / Browser combinations. They're from October 2017 but the situation hasn't changed so much. https://webaim.org/projects/screenreadersurvey7/#browsercombos

[tofumatt]

Because this isn't yet marked as in-progress I'm moving it out of the 5.0 RC milestone and into the follow-up fixes. Sorry for not getting to it in time.

[afercia]

Just tested again and this is still a problem.

Additionally, seems Ctrl + left / right arrow keys don't move the caret "by word" any longer, will create a new issue.

[afercia]

Update:

Good news: the root cause is some behavior in <ObserveTyping>: when I completely remove it from the visual editor, all the content is read out as expected. So this is definitely something in <ObserveTyping> that breaks the interaction between IE11 and JAWS.

Bad news: I have no idea why.

Will try to pinpoint the specific offending code part. However, I'd argue that playing with events, selection, timeouts, on a contenteditable (contenteditable has its own issues) seems fragile when it comes to assistive technologies and can break expected interaction at any time.

[aduth]

I might suspect it's more to do with the changes in state of the "is typing" state. ObserveTyping doesn't really manipulate events, but does observe them to cause a change in this state. The change in state is what results in the toolbars surrounding a paragraph fading away (possible DOM change interfering with JAWS?).

[afercia]

Yep, I went a bit ahead and seems it's something with isTyping, still not sure what happens exactly as caret navigation here is non-native and completely rebuilt with JS 🙁

[afercia]

Manually testing:

• block with more than 3 lines of text
• it happens (approximately) only on the first 3 lines, which is weird
• press arrow keys: moves by character > character is not read out
• same as above but this time also moving the mouse (which sets isTyping to false) while pressing arrow keys: moves by character > character is read out
  🤷‍♂️

[simison]

Has this been re-tested recently? It's been quite a while and lots has changed in the editor under the hood.

[youknowriad]

IE11 support is being dropped, context:

• https://make.wordpress.org/core/2021/03/04/discussion-dropping-support-for-ie11/
• https://make.wordpress.org/core/2021/03/25/discussion-summary-dropping-support-for-ie11/
• https://make.wordpress.org/core/2021/04/22/ie-11-support-phase-out-plan/

I'm closing this issue as it's not something we'll be investing in.