1568453 - Autofill results are read twice by screen readers

Status: VERIFIED FIXED

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

Description

[Vlad Lucaci, Desktop QA (:vlucaci)]

Affected versions

• 70.0a1
• 69.0b7
• 68.0.1
• 55.0a1 (2017-06-11)

Affected platforms

• Windows 10x64 (NVDA)
• Ubuntu 18.04x64 (Orca screen reader)
• macOS 10.14.5 (VoiceOver)

Steps to reproduce
STR (with the NVDA screen reader):

1. Open https://bugzilla.mozilla.org/
2. Submit a quick search; e.g. focus fission
3. Go back, focus the quick search field and ensure it's empty.
4. Press down arrow twice.

Expected result

• NVDA should say "list" and the first autocomplete result.

Actual result

• NVDA says the autocomplete result twice ; e.g. focus fission focus fission

Regression range

• Went as far back as 55.0a1 (2017-06-11) and the issue occurs there with the same STR. This issue is not a regression.

Comment 1

[James Teh [:Jamie]]

Morgan, this is the bug I mentioned last week. It's probably going to require some digging in both the toolkit JS code and our accessibility C++ code and figuring out how the two interact.

Simpler test case which doesn't require state:
data:text/html,<input list="datalist"><datalist id="datalist"><option>a</option><option>b</option></datalist>
If you press down arrow twice in this field, observe that the focused list item reports "a a" when it should just report "a". If you press down arrow again, observe that the second item reports "b b" instead of just "b". The accessible name (reported by Accessible::Name) is outputting the label twice for some reason.

Starting points in the code:
https://searchfox.org/mozilla-central/source/toolkit/content/widgets/autocomplete-richlistitem.js#101
Note that there are two "description" tags inside each other. My guess is that this is somehow relevant here.

Comment 2

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #1)

Starting points in the code:
https://searchfox.org/mozilla-central/source/toolkit/content/widgets/autocomplete-richlistitem.js#101
Note that there are two "description" tags inside each other. My guess is that this is somehow relevant here.

agreed, it's weird to have nested descriptions, not exactly sure why are there (naming suggest to handle text overflow), but it don't seem related. It turns out accessible name comes from @tooltip and from subtree: when changing @title, it affects on accessible name, which is also weird, because last time when I checked @title was used for accessible name as a last resort; thus I'm surprised to see it starts accessible name. If to assume that name computation alg is not guilty, then could it be something else like name caching for example (if there's a such thing).

Comment 3

[Morgan Reschenberg [:morgan]]

Hmm I think this is related to this change: https://bugzilla.mozilla.org/show_bug.cgi?id=1233672
which altered things (maybe) without concern for a11y...

Comment 4

[Morgan Reschenberg [:morgan]]

(In reply to alexander :surkov (:asurkov) from comment #2)

(In reply to James Teh [:Jamie] from comment #1)

Starting points in the code:
https://searchfox.org/mozilla-central/source/toolkit/content/widgets/autocomplete-richlistitem.js#101
Note that there are two "description" tags inside each other. My guess is that this is somehow relevant here.

agreed, it's weird to have nested descriptions, not exactly sure why are there (naming suggest to handle text overflow), but it don't seem related. It turns out accessible name comes from @tooltip and from subtree: when changing @title, it affects on accessible name, which is also weird, because last time when I checked @title was used for accessible name as a last resort; thus I'm surprised to see it starts accessible name. If to assume that name computation alg is not guilty, then could it be something else like name caching for example (if there's a such thing).

what/where is tooltip and subtree?

Comment 5

[Morgan Reschenberg [:morgan]]

Attachment: Bug 1568453: Remove the label function from autocomplete-richlistitem so that screenreaders obtain the names of autocomplete items directly from the CE markup.

Comment 6

[James Teh [:Jamie]]

(In reply to Morgan Reschenberg [:morgan] from comment #4)

what/where is tooltip and subtree?

As Morgan since discovered, it turns out that there's a label property in autocomplete-richlistitem which overrides all of our name computation code (nsIDOMXULSelectControlItemElement::label).

Comment 7

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #6)

(In reply to Morgan Reschenberg [:morgan] from comment #4)

what/where is tooltip and subtree?

As Morgan since discovered, it turns out that there's a label property in autocomplete-richlistitem which overrides all of our name computation code (nsIDOMXULSelectControlItemElement::label).

ah, right, I see it grabs @title and all stuff https://searchfox.org/mozilla-central/source/toolkit/content/widgets/autocomplete-richlistitem.js#153-168

I suppose nsIDOMXUL interfaces will go away eventually, so all stuff like this should be replaced on ARIA. Perhaps right place to put the logic into will be https://searchfox.org/mozilla-central/source/toolkit/content/widgets/autocomplete-richlistitem.js#516

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/033ed04462d0
Remove the label function from autocomplete-richlistitem so that screenreaders obtain the names of autocomplete items directly from the CE markup. r=Jamie

Comment 9

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/033ed04462d0

Comment 10

[Vlad Lucaci, Desktop QA (:vlucaci)]

Confirming this issue as verified fixed on 71.0b7(buildID:20191104135555) and 72.0a1 (buildID:20191104214406). Verified using Windows 10x64(NVDA), Ubuntu 18.04(Orca reader) and macOS 10.14(VoiceOver).