Location bar fails to read properly with NVDA when backspacing

RESOLVED FIXED in Firefox 64

Status

()

defect
P5
normal
RESOLVED FIXED
2 years ago
7 months ago

People

(Reporter: tspivey, Assigned: Jamie)

Tracking

({access})

50 Branch
Firefox 64
x86_64
Windows 10
Points:
---

Firefox Tracking Flags

(firefox64 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
STR:
1. In the location bar, type "example.com" without the quotes.
2. Press backspace several times. I hear the m, but then parts of the URL and google search are spoken.

I expect to hear the letters I'm deleting.
(Assignee)

Comment 1

2 years ago
Confirmed. When you hit backspace, for some reason, the first autocomplete list item gets accessible focus, thus taking focus away from the text box. A list item should only get focus when you press up/down arrow.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: access
Gijs, can you investigate? I can also reproduce this.
Flags: needinfo?(gijskruitbosch+bugs)

Comment 3

2 years ago
(In reply to James Teh [:Jamie] from comment #1)
> Confirmed. When you hit backspace, for some reason, the first autocomplete
> list item gets accessible focus, thus taking focus away from the text box. A
> list item should only get focus when you press up/down arrow.

This is by design in the current setup, I think. The top hit in the autocomplete list indicates what will happen if you hit enter, and so if the user input changes, it's possible the list changes and therefore the selected autocomplete entry changes too. The same thing happens if you type generally, AFAIK. What happens with accessible focus (and what does NVDA read) if you do:

1) open new tab
2) type www.google.com (or www.mozilla.org, or... - anything which produces more than a few hits with a completely matching host)
3) hit down a few times to select a different autocomplete entry that has a hostname but no trailing "/"
4) type "/"

Does the same thing happen?

Given that the selected entry in the list does change, and so presumably a11y focus is correctly reflecting that, I'm not sure what we're doing wrong. Not changing the a11y focus after a list item is selected would potentially mislead the user about what will happen (e.g. if the last thing they heard was "search for <whatever> with google", and after more user input, the top item is now 'visit <whatever.com>'), and apparently changing it is also wrong. :-\
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(jamie)
Priority: -- → P5
(Assignee)

Comment 4

a year ago
All of this weirdness is yet another casualty of the epic fail that are ARIA autocompletes.

ARIA autocompletes rely on accessibility focus being set to the selected suggestion, which is what this control is doing. This isn't so bad when you have to press down arrow to select the first suggestion. However, for controls like this one (where the first item is selected as you type), this becomes a real problem. There can only be one "focus" at a time, so when the suggestion gets "focus", the text box no longer has focus as far as a11y clients are concerned. Thus, pressing backspace won't read the character you just erased.

Where focus is being used like this, the only real solution is to never set a11y focus when the user is typing (or pressing backspace). In fact, typing should push a11y focus back to the text box. A11y focus must only be set to suggestions when down arrow or up arrow is pressed. This does mean the user can't discover what will happen when enter is pressed without pressing down arrow then up arrow, which sucks. However, what will happen is usually predictable, so this is probably a lot less annoying than the current behaviour.

Implementing this is probably going to be painful because I'll wager that as far as the UI is concerned, whether a suggestion is selected because of typing or due to manual selection is not differentiated; it's probably the same code path.

We really need to do something about this ugly situation with autocompletes, but that's going to require changes right across the a11y stack (including the spec and a11y clients).
Flags: needinfo?(jteh)
(Assignee)

Comment 5

8 months ago
This got even worse at some point. Now we're pretty much back where we were in bug 1190368, where typing or backspacing immediately gives accessible focus to the list.
NVDA issue: https://github.com/nvaccess/nvda/issues/7042
Tweet from a user switching to Chrome citing this among other reasons: https://twitter.com/mehgcap/status/1037380029443964928

Taking. I believe I have a working patch, just need to polish and write tests.
Assignee: nobody → jteh
(Assignee)

Comment 6

7 months ago
When the user is editing the text in the URL bar (typing, backspace, etc.), the first suggestion is always selected.
Because accessibility clients require autocomplete items to be "focused", the code needs to differentiate between explicit selection (e.g. via down/up arrow) and auto selection (e.g. when typing).
Otherwise, the focus continually moves away from the text box while the user is typing, as was previously occurring.
This makes it very difficult for the user to edit text, particularly backspace/delete.

There was a previous attempt to handle this, but it was somewhat fragile and broke completely some time ago.
Now, rather than trying to handle this based on autocomplete events, it is handled in the input and key press events.
For input events, accessibility focus is forced back to the text box and further accessibility focus events are suppressed.
For down arrow, up arrow, etc. key presses, accessibility focus events for suggestions are enabled.
This makes it easier to understand and predict the user experience, rather than relying on underlying autocomplete implementation details.

This is tested using an accessibility browser test, which makes it easier to make assertions about accessibility focus.
This also means that if the underlying implementation details change (e.g. HTML + aria-activedescendant instead of XUL + DOMMenuItemActive events), this test should still be valid and allow us to catch regressions.

Comment 8

7 months ago
Comment on attachment 9009505 [details]
Bug 1331755: Refactor handling of accessibility focus in the URL bar so focus never moves to suggestions while the user is editing.

:Gijs (he/him) has approved the revision.
Attachment #9009505 - Flags: review+
Comment on attachment 9009505 [details]
Bug 1331755: Refactor handling of accessibility focus in the URL bar so focus never moves to suggestions while the user is editing.

Marco Zehe (:MarcoZ) has approved the revision.
Attachment #9009505 - Flags: review+
(Assignee)

Comment 10

7 months ago
Test failures due to Mac specific behaviour of the down arrow key. New try run:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=870be6ad7978e66681fcc82a4998d09164f7836c

Comment 12

7 months ago
Pushed by jteh@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c25dbd88a42d
Refactor handling of accessibility focus in the URL bar so focus never moves to suggestions while the user is editing. r=Gijs,MarcoZ

Comment 13

7 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/c25dbd88a42d
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
You need to log in before you can comment on or make changes to this bug.