1761154 - Double speaking navigating through address bar results

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P2)

Description

[James Teh [:Jamie]]

STR (with the NVDA screen reader):

1. Focus the address bar by pressing alt+d.
2. Type asdf.
3. Down arrow as many times as needed to navigate to the first Google suggestion.
4. Press down arrow again to move to the second Google suggestion.
   • Expected: NVDA reads only the second suggestion.
   • Actual: NVDA repeats the first suggestion and then the second.

When the suggestion is unselected, the "Search with Google" suffix disappears. That causes an a11y name change event to fire. Because that suggestion is still focused, that name change is reported by screen readers.

To fix this, aria-activedescendant needs to be changed before any content in the previously selected suggestion is changed.

I'm marking this as access-s2 because although the user could just ignore the duplication, navigating the address bar suggestions is critical browser functionality and this makes this realistically unusable for screen reader users.

Comment 1

[Mandy Cheang [:mcheang][she/her]]

I moved this to Disability Access API component, but I see that Jamie, you are the triage owner for Disability Access API and you originally reported this issue to Address bar.

I'm not too familiar with screen readers so I'm going to ask Drew for some help here. Does this belong to Address bar and is it something we can fix on our team?

Comment 2

[Drew Willcoxon :adw]

Thanks Mandy, this is a problem in urlbar because we have code that sets aria-activedescendant each time the selected row changes. Based on Jamie's comment, we need to do that before hiding the "Search with Google" trailing text that appears in selected search suggestion rows.

The "Search with Google" text is called "action" text and is hidden via CSS for search rows that don't have the selected attribute. So to fix this, I think we need to set aria-activedescendant before changing the selected attribute.

Jamie marked this as a regression, but I wonder if it ever worked right? I don't recall any recent relevant changes, but maybe there was something. We should add a test for this so we catch future regressions.

Mandy, do you have time to work on this? If not I'll ask James since I owe him some ideas for bugs to work on anyway. We should fix this ASAP given the severity that Jamie mentioned.

Comment 3

[James Teh [:Jamie]]

I've never seen this double speaking before, but:

1. Was that action text always hidden for unselected items? If not, hiding it would be the regression from an a11y perspective, even though it was effectively a new feature as far as urlbar is concerned.
2. It's possible I just rarely hit Google suggestions. I tend to mostly use the address bar to search my history/bookmarks (I have search suggestions at the bottom). I'm still surprised i wouldn't have ever noticed this before now, but it's a possibility.

Comment 4

[Drew Willcoxon :adw]

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

1. Was that action text always hidden for unselected items?

Yes, it was always hidden for search suggestion rows. It's actually hidden for unselected and non-hovered search suggestion rows. If you select a search suggestion row with the keyboard or hover over it with the mouse, then the action text appears.

Comment 5

[James Teh [:Jamie]]

Oh! I think this might have regressed when a11y started (correctly) firing name change events for subtree changes in bug 1723614. While that is the correct behaviour, it causes an undesirable result in this case.

Comment 6

[Mandy Cheang [:mcheang][she/her]]

(In reply to Drew Willcoxon :adw from comment #2)

Mandy, do you have time to work on this?

I'm going to assign this one to Stephanie. I can pair with her on it.

Comment 7

[Stephanie Cunnane [:scunnane]]

To elaborate on Jamie's description of the bug, it occurs when pressing the down arrow key, and the inverse incorrect behavior happens when pressing the up arrow key. (That is, when the up arrow is pressed, NVDA reads the item immediately below the correct item first, then reads the correct item.)

Comment 8

[Marco Castelluccio [:marco]]

Stephanie, Mandy, are there any updates on this S2 bug?

Comment 9

[Mandy Cheang [:mcheang][she/her]]

Hi Marco,

At first, we tried the solution that Drew suggested in Comment 2, but that didn't fix the issue.
Stephanie has a few more notes she can add here based on her findings. It might be something that needs to be changed on a11y side, although I am not 100% sure.

I am re-assigning this bug to Daisuke as he has more experience with voiceOver and has been recently working with a11y screen reader bugs.

Comment 10

[Stephanie Cunnane [:scunnane]]

Attachment: patch.diff

Comment 11

[Stephanie Cunnane [:scunnane]]

Daisuke, this is a Windows-specific bug, since the NVDA screen reader is only for Windows.

Using the Browser Toolbox, I'm able to watch the aria-activedescendant attribute being added/removed.

Drew and I tested out some changes in UrlbarView.jsm, and I've attached a file showing a diff of those changes. However, these changes aren't fixing the issue yet.

Comment 12

[James Teh [:Jamie]]

Ug. There's a front-end bug here as identified, but it looks like there's also an a11y engine bug. Even if the label changes after setting aria-activedescendant, the a11y engine still fires the label change event before the focus event. That's... irritating. Test case:

data:text/html,<div tabindex="0" role="listbox" aria-activedescendant="a" onkeydown="if (event.key == 'ArrowDown') { this.setAttribute('aria-activedescendant', 'b'); a.setAttribute('aria-label', 'a1'); }"><div id="a" role="option">a</div><div id="b" role="option">b</div></div>

Comment 13

[James Teh [:Jamie]]

(In reply to Stephanie Cunnane from comment #11)

Daisuke, this is a Windows-specific bug, since the NVDA screen reader is only for Windows.

It may well be reproduceable on other platforms as well, though. I just provided STR with NVDA since Windows is what I have access to here.

Comment 14

[James Teh [:Jamie]]

I just came up with an a11y engine patch for bug 1192108 which fixes this without any front-end change. (I was looking to fix the problem I noted in comment 12, but the fix I came up with solves the problem without needing to change the order of things in front-end, which is a bonus.) However, it's a bit risky and I'm going to have to sift through the test failures to work out whether any of them are actually a real problem.

Comment 15

[James Teh [:Jamie]]

The fix for bug 1192108 landed and stuck. I've verified that it fixes this address bar issue.

Comment 16

[Petruta Horea [:phorea], Desktop QA]

Reproduced in Firefox 100, verified as fixed using Firefox 102 beta 6 under Win 10 64-bit.