Application of Certain Roles Prevents Review and Editing of Text Inside contenteditable Nodes

[jscholes]

Summary

When certain roles are applied to a node with contenteditable="true", JAWS no longer allows the content to be reviewed and edited in forms mode. As an example of reproducing this problem:

1. Go to https://jscholes.github.io/contenteditable-with-role.html
2. Using the JAWS Virtual Cursor, navigate to the start of the editable main landmark. This is marked up as a <div> with role="main" and contenteditable="true".
3. Press Enter to enable Forms Mode (if not automatically activated).
4. Attempt to review the editable section with all four Arrow keys.

Expected result

JAWS will allow users to navigate by character, word, line, etc., speaking the text and semantics as they do so.

Actual result

JAWS stays completely silent when the Arrow keys are pressed, not even announcing "blank" or similar.

Example

https://jscholes.github.io/contenteditable-with-role.html

Additional Information

JAWS version and build number

2020.2008.24 ILM

Operating System and version

Windows 10 Professional version 1909, build 18363.836

Browser and version:

• Mozilla Firefox 80.0.1 (64-bit)
• Google Chrome 85.0.4183.83 (Official Build) (64-bit)

Notes

The linked example uses a role of "main", but the behaviour was also observed when using the following roles (may not be an exhaustive list):

• complementary
• contentinfo
• form
• main
• navigation
• search
• region
• note

The behaviour occurs irrespective of whether the role is explicitly applied (as in the example) or implied through the use of <main>, <header> and other semantic HTML elements.

CC @sinabahram

[JAWS-test]

Tested in Chrome and JAWS 2020: The problem always occurs when contendeditable is used, even without landmark elements or ARIA roles, i.e. with <div contenteditable=true>

[jscholes]

@JAWS-test That's definitely not what I'm seeing. Do you have a test case, and what settings are you using for forms mode activation?

[sinabahram]

Agreed with @jscholes , not what I'm seeing over here either @JAWS-test

[JAWS-test]

Do you have a test case, and what settings are you using for forms mode activation?

I used your test page and removed role=main.

I have tested with automatic and semi-automatic forms mode. In both cases the problems occurred in forms mode.

This may be due to the JAWS version. I have 2020.2006.

[jscholes]

@JAWS-test All tests on my end were carried out with forms mode activation set to manual; could you give that a go?

I used your test page and removed role=main.

Did you download the file and load the page with role="main" removed, or remove it in the browser dev tools?

[JAWS-test]

Did you download the file and load the page with role="main" removed, or remove it in the browser dev tools?

Both.

I have now tested it on another computer with Chrome and the same version of JAWS and have the same test results as you. I have not been able to find out why the first computer I used had different test results. Sorry for the confusion I caused...

[JAWS-test]

Possibly the problem is related to https://github.com/FreedomScientific/VFO-standards-support/issues/241, at least there is the similarity that it

• also occurs in landmark regions
• also occurs with input fields in forms mode

[frex65]

Bug confirmed using JAWS 2020.2008.24, Chrome 85.0.4183.121 and FF 81.0. In IE11, content inside the contenteditable <div> is read correctly, but it's not possible to exit the field and read surrounding content.