1566299 - Autocomplete results no longer reported by screen readers

Status: VERIFIED FIXED

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

Description

[James Teh [:Jamie]]

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: NVDA should say "list" and the first autocomplete result.
   • Actual: Only "blank" is announced.

Impact: This makes it impossible for screen reader users (and potentially users of other a11y clients) to use browser autofill.

4:20.45 INFO: Last good revision: 1bb2ca14033de2be56fa5dee85fed2e0fc961b0b
4:20.46 INFO: First bad revision: a83c218cd961857e02be7bac0ff9c971b026c4ce
4:20.47 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1bb2ca14033de2be56fa5dee85fed2e0fc961b0b&tochange=a83c218cd961857e02be7bac0ff9c971b026c4ce

This was a regression introduced by bug 1525101.

Comment 1

[James Teh [:Jamie]]

I'm putting this in Disability Access APIs for now, but it might end up requiring a change to the XUL widget.

Comment 2

[James Teh [:Jamie]]

Adjusting the summary because preliminary investigation suggests it's possible that events are being fired but that there's something wrong with them; e.g. missing focused state. Investigating further.

Comment 3

[James Teh [:Jamie]]

I have a patch.

Comment 4

[James Teh [:Jamie]]

So we have accessible/tests/mochitest/events/test_focus_autocomplete.xul which is supposed to test this, but it was disabled on Windows, Linux and Mac due to intermittent failures (bug 695019, bug 890795, bug 746177). I'm not going to try to fix that right now. It's a pretty big/complex test, it looks like there's a lot of painful history in trying to fix it and I fear this will just delay us from getting the current bug fixed. Obviously, we should try to get this test working in the long-run (or at least strip it down to something which at least tests the basic functionality).

Comment 5

[James Teh [:Jamie]]

Attachment: Bug 1566299: Update XULListBoxAccessible now that autocomplete-richlistbox-popup is a Custom Element.

In bug 1525101, autocomplete-richlistbox-popup was converted to a Custom Element.
This means we can no longer use do_QueryInterface to get nsIAutoCompletePopup.
Instead, we must use Element::AsAutoCompletePopup.
This fixes accessibility focus for these autocompletes.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1d93214e55be
Update XULListBoxAccessible now that autocomplete-richlistbox-popup is a Custom Element. r=surkov

Comment 7

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/1d93214e55be

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta and ESR68 approval when you get a chance.

Comment 9

[James Teh [:Jamie]]

Comment on attachment 9078324 [details]
Bug 1566299: Update XULListBoxAccessible now that autocomplete-richlistbox-popup is a Custom Element.

Beta/Release Uplift Approval Request

• User impact if declined: Browser autofill will be inaccessible to screen reader users (and potentially users of other accessibility tools).
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Trivial change which impacts a very specific area of code (XUL list box accessibility).
• String changes made/needed: None.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Accessibility fix for a core browser function.
• User impact if declined: Browser autofill will be inaccessible to screen reader users (and potentially users of other accessibility tools).
• Fix Landed on Version: 70; also requesting uplift to 69
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Trivial change which impacts a very specific area of code (XUL list box accessibility).
• String or UUID changes made by this patch: None.

Comment 10

[James Teh [:Jamie]]

Verified fixed in Firefox 70.0a1 20190718095458 64 bit on Windows.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9078324 [details]
Bug 1566299: Update XULListBoxAccessible now that autocomplete-richlistbox-popup is a Custom Element.

Fixes a regression causing broken browser autofill for screen reader users. Verified fixed on Nightly builds. Approved for 69.0b7 and 68.1esr.

Comment 12

[Razvan Maries]

https://hg.mozilla.org/releases/mozilla-beta/rev/07d0601ce171

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-esr68/rev/8e5f6cec66c6

Comment 14

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Hello,
I have managed to reproduce this issue on Windows 10x64 with FF Nightly from 70.0a1 (2019-07-15) and NVDA 2019.1.1.

I have the following results on the fixed flags:

For 69.0b7 and 70.0a1 (2019-07-22) , although the NVDA Narrator no longer announces "blank" when following the STR from above a new behavior can be observed; The search term from the search drop down is announced twice. (eg: "fission focus" is narrated "fission focus fission focus")
This issue does not occur for the latest Chrome browser for example. The search terms there are only stated once.

For 68.0.1esr however, the issue still occurs with the same STR as in the Description.

Should I file a different bug for the new behavior of 69.0b7 and 70.0a1 (2019-07-22) flags, seeing as how on ESR the issue still occurs with the same steps?

Comment 15

[James Teh [:Jamie]]

(In reply to Vlad Lucaci, QA (:vlucaci) from comment #14)

For 69.0b7 and 70.0a1 (2019-07-22) , although the NVDA Narrator no longer announces "blank" when following the STR from above a new behavior can be observed; The search term from the search drop down is announced twice. (eg: "fission focus" is narrated "fission focus fission focus")
This issue does not occur for the latest Chrome browser for example. The search terms there are only stated once.

Confirmed. Note, however, that I'm pretty sure this isn't a regression; i.e. this happened in Firefox <= 66.

For 68.0.1esr however, the issue still occurs with the same STR as in the Description.

I know this was uplifted to ESR (see comment 13), but has it actually made it into an ESR build yet?

Should I file a different bug for the new behavior of 69.0b7 and 70.0a1 (2019-07-22) flags, seeing as how on ESR the issue still occurs with the same steps?

Yes please. Thanks.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

It was uplifted for 68.1esr, not 68.0.1esr.

Comment 17

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #16)

It was uplifted for 68.1esr, not 68.0.1esr.

I have re-verified this issue with 68.1esr and can confirm that the issue is fixed, however the above described new behavior is also present.

As per agreed in Comment 15, I will open a different ticket for the new behavior.

Confirming this issue as verified fixed for 69.0b7 and 70.0a1 (2019-07-22) and 68.1esr on Windows 10x64.