Closed Bug 1566299 Opened 3 months ago Closed 3 months ago

Autocomplete results no longer reported by screen readers

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- verified
firefox68 --- wontfix
firefox69 --- verified
firefox70 --- verified

People

(Reporter: Jamie, Assigned: Jamie)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

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.

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

Has Regression Range: --- → yes
Has STR: --- → yes

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.

Summary: Autofill no longer fires accessibility focus events → Autofill no longer reported by screen readers

I have a patch.

Assignee: nobody → jteh

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

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.

Pushed by jteh@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1d93214e55be
Update XULListBoxAccessible now that autocomplete-richlistbox-popup is a Custom Element. r=surkov
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

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

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.
Flags: needinfo?(jteh)
Attachment #9078324 - Flags: approval-mozilla-esr68?
Attachment #9078324 - Flags: approval-mozilla-beta?

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

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.

Attachment #9078324 - Flags: approval-mozilla-esr68?
Attachment #9078324 - Flags: approval-mozilla-esr68+
Attachment #9078324 - Flags: approval-mozilla-beta?
Attachment #9078324 - Flags: approval-mozilla-beta+
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

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?

Flags: needinfo?(jteh)

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

Flags: needinfo?(jteh)

It was uplifted for 68.1esr, not 68.0.1esr.

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

Status: RESOLVED → VERIFIED
Flags: qe-verify+
See Also: → 1586001
Summary: Autofill no longer reported by screen readers → Autocomplete results no longer reported by screen readers
You need to log in before you can comment on or make changes to this bug.