No indication given to the user that a WYSIWYG field already contains text

[mgifford]

Type of report

Bug

Provide detailed reproduction steps (if any)

1 Create a node that has that has a ckeditor field.
2 Open JAWS v18.0.2945.
3 Edit that node.
4 Use the Tab key to navigate to the ckeditor field.

Expected result

All textual information is expected to be announced.

Actual result

When editing a entity that already has content contained in it and a user tabs to a WYSIWYG field, JAWS users in chrome receive no indication that there is already content in the field.

• Testing was performed using JAWS v18.0.2945.

Notes browser behavior for text fields:

• Regular text field behavior: In both Chrome and IE, JAWS will read the text automatically when you tab to a regular text field
• Textarea field behavior: In both IE and Chrome, JAWS will announce that field has text, but will not read it.

WYSIWYG Field behavior:

• In Chrome, JAWS reads nothing and does not indicate that there is text in the field at all. A user needs to use the insert+down arrow command to read the text. (This shortcut is not announced to the user in any way. This shortcut was discovered during testing using JAWS).
• In IE it will auto read the WYSIWYG text, but only the first line of the field. In order for it to read the remaining text you will need to use the keyboard insert+down. (This shortcut is not announced to the user in any way. This shortcut was discovered during testing using JAWS)

Other details

Originally reported here https://www.drupal.org/project/drupal/issues/3002056

• Browser: Chrome

[mlewand]

When it comes to screen reader support we target for latest FF + latest JAWS support.

And I know that JAWS is properly reading the content of editor (if any) when focusing the editor. I used our CDN sample to use unmodified CKE4 instance.

I tested JAWS with FF but also with IE8, both cases are properly indicating that there is a content and what is the content next to the selection. Can you verify this on your end? Maybe it's due to outdated JAWS version.

Here are screen recording just for the reference: screen reader #2499.zip. I used JAWS 2018.1808.10 + FF 62.0.3.

In case it does not work with other screen reader / browser combination it make sense to report it to proper upstream vendor.

[mgifford]

Thanks @mlewand - always nice to have broader coverage given that IE is still so popular in the blind community and that VoiceOver is also raising in popularity. Anyways, know there is limited time/resources.

So I'll point the original person to post a follow up here.

[afemath]

@mgifford Thank you for up-streaming this. I sent it to a tester and he is retesting it. he should comment soon.

[MegaMan8990]

I retested the issue using JAWS 2018.1808.10 and encountered the same bug as before. In IE11 JAWS will only read the first line of text in the WYSIWYG field unless you press insert and the down arrow key. I also tried Firefox, but the results were the same as when we ran the test in Chrome. In Firefox, JAWS will say what the field is, but will not read the text within the field.

[mlewand]

Have a look at vids attached to #2499 (comment) - it contains a recording with FF and it works. I wonder what is the difference? I'm using the default setup so I can't see the reason why it would give different results.

[Comandeer]

Using the JAWS 2019.1906.10 I can confirm that Firefox and IE reads the first line of the text. Chrome OTOH sometimes just announces that the field contains text and sometimes just announces that the focus is in editable field.

Additionally the way in which editor is announced upon a focus is different depending on editor type (inline or iframe-based). In case of the inline one, behaviour of Firefox changes and it limits the announcement to the fact that the editor contains text, without reading anything.

IMO the behaviour of Firefox with iframe-based editor (announcing the editor and reading the first line of text) is the most correct one and we should further investigate why inline editors and behaviour in Chrome are different.

[f1ames]

Related issues - #1904, #2445.

[CKEditorBot]

Closed in #5146

[jacekbogdanski]

This ticket shouldn't be closed by #5146 itself as the issue has not been fixed.

However, from our research, the issue looks like JAWS upstream. In Firefox (which is used by us as a browser of choice for accessibility compliance) everything works fine. However, in the case of Chrome, JAWS specifically dictates "contains text" when focusing contentEditable without reading the text itself. We believe that's the limitation of JAWS software as it seems to be no proper way to force JAWS to read the text properly using aria-labels. Therefore, I'm leaving this ticket closed as an upstream.