1616829 - List items in contenteditable content lack ATK_STATE_EDITABLE

Status: RESOLVED FIXED

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

Description

[Joanmarie Diggs]

Steps to reproduce:

1. Compose a new message in Gmail's rich text editor with one bulleted list item.
2. Use Firefox's built-in accessibility inspector to examine the state the accessible list item.
3. Compare the results from step 2 with what is seen in Accerciser.

Expected results: State editable would be present in both steps 2 and 3.

Actual results: State editable is present in step 2, but not in step 3. This suggests that the "editable" state is being removed at the ATK/platform level.

Impact: Orca ignores certain text-changed events when the object is not editable. For instance, when a character is deleted, Orca checks to see if the accessible object is editable before announcing the text change.

Comment 1

[James Teh [:Jamie]]

I'm guessing the culprit is this code which removes the editable state if the readonly state is set. We set the readonly state on list items to differentiate them from list box options, since these both get mapped to the "list item" role for both Windows and ATK. (That said, it looks like we're mapping option incorrectly anyway; it should be ROLE_MENU_ITEM for ATK according to the spec.)

I need to think about how to fix this without breaking Windows.

Comment 2

[Joanmarie Diggs]

This also impacts Thunderbird though in a different way: It causes Orca to double-present inserted text in editable list items when both character echo and key echo are enabled. The reason why is that Orca's logic to prevent double-presentation when the user has both of these settings enabled assumes that editable items will have the editable state.

Comment 3

[Alex ARNAUD]

I've reported this one against Orca 1 day ago but I'm pretty sure this is a regression, I don't encounter this issue in the past.

IMO the impact is important because announcing twice a character will prevent the user to determine what he really types.

Comment 4

[James Teh [:Jamie]]

I am almost certain this is not a regression, at least not in Firefox. This particular code has been the same for a very long time.

Comment 5

[James Teh [:Jamie]]

Attachment: Bug 1616829: Don't remove ATK_STATE_EDITABLE from list items in editors.

Comment 6

[James Teh [:Jamie]]

Joanie, the attached patch should fix this. However, with that applied, Orca won't read content editable list items by character any more. Instead, it reads the entire list item on each press of right/left arrow. Note that I'm probably using some ancient version of Orca - I need to find the time to upgrade this Linux vm - so it's possible this is the cause. It'd be great if you can let me know whether this patch does as you need. Let me know if you need a try build. Thanks!

Comment 7

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

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 8

[Joanmarie Diggs]

Jamie: A try build would be great. Thanks!

Given that Orca works correctly with Chromium (which doesn't have this bug), I'm guessing things will be fine. And there has been a lot of work done in Orca related to contenteditable elements in just the past couple of months.

Comment 9

[James Teh [:Jamie]]

Here you go:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NNb74c8sTGGmr2IqcGwQKw/runs/0/artifacts/public/build/target.tar.bz2

Comment 10

[Joanmarie Diggs]

Thanks Jamie!

This seems to solve the problem both for the issue mentioned in the opening report as well as the double-echoing (I was able to reproduce the same issue in Gmail's rich text editor). And when I arrow left and right, Orca just presents the character; not the full line.

Really appreciate it!

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3789a12084e4
Don't remove ATK_STATE_EDITABLE from list items in editors. r=MarcoZ

Comment 12

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/3789a12084e4