1676662 - In contentEditables, list items are not exposed, and the whole text cannot be navigated by character with VoiceOver.

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect, P1)

Description

[Marco Zehe (:MarcoZ)]

Steps:

1. Open data:text/html,<div contentEditable="true" role="textbox" aria-multiline="true"><p>This is a paragraph.</p><ul><li>List item 1</li><li>List item 2</li></ul><ol><li>Numbered item 1</li><li>Numbered item 2</li><li><ol><li>Inner item 1</li><li>Inner item 2</li></ol></li></ol><h1>A heading</h1><p>Another paragraph.</p></div>.
2. Focus the contentEditable and arrow through it.
   • Expected: VoiceOver reads the bulleted and numbered list items with their bullets and numbers respectively.
   • Actual: VoiceOver only reads the text.
3. Press Ctrl+Option+Shift+DownArrow to interact with the text box, then Ctrl+Option+Shift+RightArrow to navigate the text character by character.
   • Expected: All the text could be navigated.
   • Actual: Results are very inconsistent. Either only text from the current paragraph is visible, meaning the one the cursor is in, or VoiceOver reads some arbitrary text from the browser UI instead.

In both Chrome and Safari, both the bullets and numbers are exposed, as well as the full text can be navigated when performing the above step 4.

This may be closely related to, or even a dupe of, bug 1672700. But filing it separately because it affects speech, too.

This prevents richly formatted documents in Google Docs, like our VoiceOver testing scenarios, from being read properly. The numbering and nested numbering from those lists is not communicated by Firefox. The heading, however, is.

Comment 1

[Marco Zehe (:MarcoZ)]

This is an issue in Google Docs. Nominating for fixing in 85 for consumer preview.

Comment 2

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1676662 - Prepend list bullet when getting range at start of list item. r?morgan!

Safari has an inconsistent way to deal with list bullets in text.
If a given range has a list or list item nested inside it - but it is not
at the beginning, the bullet will not be returned as part of the text.But if the range begins at the start
of a list item, the preceding bullet is included. For example, given the following list:

• First Item
• Second Item

If the range is [irst Item], the text for that range should return as "irst Item",
but if the range is [First it], the returned text is "* First it".

This patch emulates that inconsistency by removing the list item considerations
in the text segments iterator, and instead prepending a bullet if needed.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f62764a6d94d
Prepend list bullet when getting range at start of list item. r=morgan

Comment 4

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/f62764a6d94d

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:eeejay, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 6

[Eitan Isaacson [:eeejay]]

It is not important enough for uplift. Thanks!

Comment 7

[Catalin Sasca, Desktop QA [:csasca]]

I've reproduced the issue on Firefox 84.0a1 (2020-11-11) under macOS 11.1

The issue is fixed on Firefox 85.0b3 and 86.0a1 (2020-12-18). Tests were performed on macOS 11.1