1322621 - Removing aria-activedescendant while element is focused doesn't adjust accessible focus

Status: VERIFIED FIXED

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

Description

[James Teh [:Jamie] (away returning 28 Jan)]

Attachment: Test case.

STR:
1. Open the attached test case.
2. Tab to the list. The item will get focus.
3. Press escape.
Expected: A focus event should be fired on the list and the list should get the focused state.
Actual: No focus event is fired. The list item keeps the focused state.

This breaks the autocomplete in the Javascript console. For example, when the autocomplete appears, pressing escape doesn't return accessible focus to the input box.
This used to work, so this seems to be a regression. I have no idea when it regressed yet, though.

Comment 1

[Marco Zehe (:MarcoZ)]

Alex, any ideas?

Comment 2

[alexander :surkov (:asurkov)]

It looks like DocAccessible::ARIAActiveDescendantChanged should call FocusManager::ActiveItemChanged in this case too. Now we call ActiveItemChanged only if active item is not null.

If this is a regression, then it must be pretty old one.

Comment 3

[James Teh [:Jamie] (away returning 28 Jan)]

Bug 977267 (landed August 2014) relies on this working. I'm not sure when it broke after this, but I feel like it was only some time this year. I'll try to narrow it down at some point.

Comment 4

[James Teh [:Jamie] (away returning 28 Jan)]

Sorry. It seems I was wrong: this isn't a regression after all. I think the reason this seemed to work previously for bug 977267 is that the autocomplete items previously got removed when the autocomplete was dismissed. Now, they don't; they're still present, even though they're not shown visually. So, this is still a bug that needs to be fixed, but it isn't a core a11y regression.

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

Probably best to file a new bug in the right component (and DUPE this one to it). Morphing this one would add confusion/noise to the problem.

Comment 6

[James Teh [:Jamie] (away returning 28 Jan)]

On the contrary, this bug as described is definitely a bug in core a11y. It isn't a regression, but it's still broken. The JavaScript Console autocomplete regressed due to a change in the implementation, but at the end of the day, if this core a11y bug didn't exist, it would still work as expected. To put it another way, if I file a bug to fix the JS Console, they'd basically just be hacking around a core a11y bug.

Comment 7

[Marco Zehe (:MarcoZ)]

I definitely agree with Jamie here.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

This is something we should triage and fix but isn't among our most urgent bugs.(Contributions welcome as always!)

Comment 9

[James Teh [:Jamie] (away returning 28 Jan)]

Attachment: Bug 1322621: If aria-activedescendant is removed or changed to an invalid id while an element is focused, move accessible focus to the element itself.

Comment 10

[alexander :surkov (:asurkov)]

Comment on attachment 9005534 [details]
Bug 1322621: If aria-activedescendant is removed or changed to an invalid id while an element is focused, move accessible focus to the element itself.

alexander :surkov (:asurkov) has approved the revision.

Comment 11

[James Teh [:Jamie] (away returning 28 Jan)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=627b3d1e5af90e053886778004615140ff45fc79

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eac4056f176a
If aria-activedescendant is removed or changed to an invalid id while an element is focused, move accessible focus to the element itself. r=surkov

Comment 13

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/eac4056f176a

Comment 14

[Mihai Boldan, Desktop QA [:mboldan]]

Attachment: New test case.html

I managed to reproduce this issue on Firefox 55.0a1 (2017-04-25), under Windows 10x64, using this new Test Case received from James Teh, since the one from Comment 0 is outdated.
The issue was verified on Firefox 63.0b6 and on Firefox 64.0a1 (2018-09-13) under Windows 10x64.
Note that I was not able to verify the issue on Mac OS and on Ubuntu OS, since the screen reader app is not reading from browsers.

Comment 15

[Mihai Boldan, Desktop QA [:mboldan]]

James, please let me know if do you think that there is something else that we should cover for this issue.

Comment 16

[James Teh [:Jamie] (away returning 28 Jan)]

(In reply to Mihai Boldan, QA [:mboldan] from comment #14)
> Note that I was not able to verify the issue on Mac OS and on Ubuntu OS,
> since the screen reader app is not reading from browsers.

This should work correctly in Ubuntu with Orca (the screen reader). However, I don't know *exactly* what the screen reader should say in this case. Still, I'm happy with this testing; there shouldn't be any reason this would behave differently on other platforms, barring more general bugs on those platforms.

Comment 17

[Mihai Boldan, Desktop QA [:mboldan]]

Based on Comment 16, I'm marking the issue Verified Fixed.