1363324 - Accessibility - On mouse hover the autocomplete results are no longer read by the screen reader

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect, P1)

Description

[Simona Badau, Desktop QA]

[Affected versions]:
- Nightly 55.0a1

[Affected platforms]:
- Ubuntu 16.04 and Mac OS X 10.11

[Steps to reproduce]:
On Ubuntu - Start Orca screen reader - from Universal Access -> Screen Reader - ON

[Steps to reproduce]:
1. Launch Nightly
2. Start typing in the URL Bar
3. Hover your mouse over the autocomplete results and over the one-off buttons

[Expected result]:
- The autocomplete results and the one-off buttons should be read on mouse hover 

[Actual result]:
- The autocomplete results are not read on mouse hover (only the one-offs are read)
- The autocomplete results are read if selected using the down arrow key.

[Regression range]:
Last good revision: f40e24f40b4c4556944c762d4764eace261297f5
First bad revision: bc086e9044e6537d18d385f417248cdb4c14c3af
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f40e24f40b4c4556944c762d4764eace261297f5&tochange=bc086e9044e6537d18d385f417248cdb4c14c3af

Comment 1

[Simona Badau, Desktop QA]

Drew, could this be related to the landing of Bug 1295458?

Comment 2

[Simona Badau, Desktop QA]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0

This issue is not reproducible using the latest Nightly 55.0a1 (BuilD ID: 20170509030205) on Windows with NVDA.

Comment 3

[Drew Willcoxon :adw]

Thanks Simona, I'll take a look at this.  Marking P1 since this is important for shipping.

Comment 4

[Drew Willcoxon :adw]

Marco, would you mind letting me know your thoughts about this?

I'm pretty sure this bug is happening because we're no longer firing select events when you hover over an item in the URL bar popup.  That's because hover no longer selects.  If hover no longer selects, how should accessibility apps be notified on hover?  Should they be notified at all?  The point of turning hovered items gray is to let you know you can select them when you click.  How does that concept translate in the context of accessibility?

Comment 5

[Marco Zehe (:MarcoZ)]

Sorry for the delay in answering!

OK, there are a few things here.

1. Blind people are probably the least target users for mouse hover interactions. We can't see the mouse, and thus will not very likely use it much to interact with things.

2. Is not firing select events on mouse hover consistent with other ATK/GNOME apps on Linux? I am not that familiar with that platform and its user interaction.

3. The reason why this works on Windows with NVDA is simply that NVDA reads automatically whatever is under the mouse. So the talking comes from hovering over the item per se, not from a select event.

4. The most likely way of interacting with this is by arrow keys for auto complete items, and tabbing from the search field to the one-off buttons. As long as these still work, I'm fine.

5. And about the turning gray part... Isn't that very counter-intuitive visually? Grayed out items are usually disabled, cannot be clicked, or clicking on them doesn't do anything. So turning them gray sounds to me like a quite pattern-breaking change. Also, I believe it violates the WCAG criterium of "don't indicate something by color alone". People who have difficulty seeing subtle color changes will probably not notice this right away. So taking away the selection actually broke things, but not necessarily in the way this bug initially indicates. This visual change and inconsistency in patterns will probably be a problem for people with cognitive or visual impairments much more than for screen reader users.

David, can you give this a visual look-over, please? It sounds to me like there are some breaking changes here...

Comment 6

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Marco Zehe (:MarcoZ) from comment #5)
> 2. Is not firing select events on mouse hover consistent with other
> ATK/GNOME apps on Linux? I am not that familiar with that platform and its
> user interaction.

Me neither, but I don't think the UX team would have prioritized consistency with other Linux apps over Firefox cross-platform consistency in any case. The awesomebar results panel is not a panel with native looks or behavior.

> 4. The most likely way of interacting with this is by arrow keys for auto
> complete items, and tabbing from the search field to the one-off buttons. As
> long as these still work, I'm fine.

This leads me to agree with Drew that this bug is a wontfix. It certainly doesn't qualify as a blocker for shipping the feature.

> 5. And about the turning gray part... Isn't that very counter-intuitive
> visually? Grayed out items are usually disabled, cannot be clicked, or
> clicking on them doesn't do anything. So turning them gray sounds to me like
> a quite pattern-breaking change. Also, I believe it violates the WCAG
> criterium of "don't indicate something by color alone". People who have
> difficulty seeing subtle color changes will probably not notice this right
> away. So taking away the selection actually broke things, but not
> necessarily in the way this bug initially indicates. This visual change and
> inconsistency in patterns will probably be a problem for people with
> cognitive or visual impairments much more than for screen reader users.

The change is not pattern-breaking as in Firefox 53 hovering with the mouse doesn't properly select the entry, in the same way that using the arrow keys does. It only confusingly displays it with the same highlight as a selected entry, without updating the awesomebar field. This change was about fixing that discrepancy and the gray highlight is a way to retain some indication about which row the mouse is over.

I'm not sure if the color contrast is enough for visually impaired users, but it is what UX gave us. If this color seems inadequate in that regard, let's file a followup to improve it and I will ask UX to figure out what the right one would be. But again, keep in mind that it is *supposed* to have a low contrast against the background color.

> David, can you give this a visual look-over, please? It sounds to me like
> there are some breaking changes here...

I want to hear David's thoughts before deciding to resolve this issue or keep it in the backlog. However, the latter would require buy-in and some amount of redesign from the UX team.

Comment 7

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

Adding Joanie since she is the Orca maintainer and closest to knowing the impact here.

Comment 8

[Drew Willcoxon :adw]

Thanks Marco.  I meant to reply to this yesterday.

(In reply to Marco Zehe (:MarcoZ) from comment #5)
> 3. The reason why this works on Windows with NVDA is simply that NVDA reads
> automatically whatever is under the mouse. So the talking comes from
> hovering over the item per se, not from a select event.

Oh, interesting.  In that case, I'm guessing there should be basically no difference between the new and old behavior regarding hover.

> 4. The most likely way of interacting with this is by arrow keys for auto
> complete items, and tabbing from the search field to the one-off buttons. As
> long as these still work, I'm fine.

Yes, this behaves the same as before.  The arrow keys still change the selection.

> 5. And about the turning gray part...

That's a good perspective.  Like Panos said, it was a UX decision, so we need to rope them in on potential changes.

Comment 9

[Simona Badau, Desktop QA]

Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170606100219

The search suggestions hint is also not read on Mac OS X 10.12 (using "Voice Over")and Ubuntu 16.04 (using "Orca Screen Reader") using Nightly 55.0a1 (this issue does not reproduce on Windows with NVDA).

Comment 10

[Panos Astithas (he/him) [:past] (please ni?)]

Since no new information has appeared to challenge the outcome of the above discussion, I am closing this bug as the behavior is as designed by UX. Let's file new bugs if there is actually a concrete proposal with UX buy in for the suggestion in comment 5.