Closed Bug 1568453 Opened 4 months ago Closed Last month

Autofill results are read twice by screen readers

Categories

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

Desktop
All
defect

Tracking

()

VERIFIED FIXED
mozilla71
Tracking Status
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- verified
firefox72 --- verified

People

(Reporter: vlucaci, Assigned: morgan)

References

Details

Attachments

(1 file)

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.
Has Regression Range: --- → no
Has STR: --- → yes
Priority: -- → P2

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.

Assignee: jteh → mreschenberg

(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).

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...

(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?

Flags: needinfo?(surkov.alexander)

(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).

Flags: needinfo?(surkov.alexander)

(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

Attachment #9097422 - Attachment description: Bug 1568453: If the displayURL and title match on an autofill, only pass one to the screen reader to avoid repetition. → Bug 1568453: Remove the label function from autocomplete-richlistitem so that screenreaders obtain the names of autocomplete items directly from the CE markup.
See Also: → 1586001
Pushed by mreschenberg@mozilla.com:
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
Status: NEW → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

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).

Flags: qe-verify+
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.