Some additional context, this issue is relevant to work I'm doing to make Slack accessible to customers using VoiceOver. Any movement on this bug, or suggested hacks would be greatly appreciated by our customers.

Reporter@ Thanks for the issue.

Able to reproduce the issue on Mac OS 10.13.3 on the latest Canary 67.0.3379.0 and Stable 65.0.3325.181 by following the given steps above.

The system focus is not in sync with VoiceOver cursor as in Safari.
Attached is the screen cast for reference.

This is a Non-Regression issue as this behavior is observed from M60 Chrome builds. 
Hence marking this as Untriaged for further updates from Dev.

Thanks..

Deleted: 825715.mp4 1.6 MB

	825715.mp4 1.6 MB View Download

Thanks for validating this bug Susan. What’s the imagined turnaround time for this issue? Reason I ask: fixing this is key to us being able to deliver a quality user experience for Slack users who rely on screen readers. And so, we really could use some signal from the Chrome team as to: if this can be fixed, if so by when. OR, is this a bug upstream from you all and requires a fix from Apple. If that’s the case then I need to know so I can notify Apple.

Anyway, any and all detail would be greatly appreciated.

Any update on this bug? I see it is still not triaged.

I can reproduce some of this but it's flaky for me and I don't fully understand what's going on.

I opened your page in Chrome 66.0.3359.66 and at first I was seeing the bug - I pressed Tab and then arrow keys, and VoiceOver was speaking each list item, but visually it was still focused on the list, and pressing VO+right-arrow moved to the first list item.

I then tried it in Safari and VO followed the arrows but only focused and read out a single word. Are you seeing that?

Then I tried toggling "Always allow keyboard commands to navigate websites" off in VoiceOver utility. That made no difference in Safari, but when I went back to Chrome it now worked correctly.

However, when I toggle that setting back on, I can't reproduce the bug anymore.

This definitely seems like a quirk in VoiceOver, we might want to loop in Apple to get a better understanding of it.

I'd be curious if anyone else can reproduce the issue changing if you toggle "Always allow keyboard commands to navigate websites".

Dominic,

Thanks for having a look at this ticket.

I dug in a bit deeper and the problem is rooted in our choice of keyboard shortcut being the up and down arrow keys. I attached a modified example (test2.html) that uses j and k to move focus between items in the list and the VoiceOver cursor syncs with the system focus and you can switch between focus navigation and VoiceOver navigation.

Clearly Apple has mapped some default VO behavior to the up and down arrow keys that cannot be changed by the "Always allow keyboard commands to navigate websites" preference. Either that, or there's a bug with that pref. I followup with Apple. I don't think there's an action item here for the Chrome team, so I consider this one resolved on your end.

Thanks,
Todd

Deleted: test2.html 2.6 KB

test2.html 2.6 KB View Download

Dominic,

I dug even deeper into this and discovered the issue was the keydown event listener wasn't calling preventDefault() when handling the arrow keys. I _suppose_ that makes sense—VoiceOver needs some signal as to if the application is overriding the default up/down arrow key behavior. With use of preventDefault() the test case (see attached test3.html) works as expected: up/down arrow keys move system focus between the items and the VoiceOver cursor stays in sync.

The only trouble is the while the test case now works consistently well between Chrome and Safari on the Mac, I can still reproduce the bug in Slack—which uses the same HTML structure, ARIA roles and is already calling preventDefault() in the arrow keydown handler.

Todd   

Deleted: test3.html 2.6 KB

test3.html 2.6 KB View Download

Dominic,

Hi, me again. :) I've dug even deeper into this one and discovered getting the  VoiceOver cursor to track to the system focus in Chrome isn't entirely dependent on the use of preventDefault() as I previously thought it was. It also requires the use of aria-label with the each ARIA listitem.

This is why test case 3 (test3.html) works consistently well between both Chrome and Safari with VoiceOver; in that example I had added an aria-label to each ARIA listitem element. Neither of the two previous test cases leveraged aria-label.

So, with that, I've attached a fourth test case (test4.html) that is essentially test3.html without the aria-label applied to each listitem. When you compare this example between Safari and Chrome you'll notice the difference we're seeing in Slack:

In Safari:
When the system focus is on an ARIA listitem, the VO cursor is placed inside the item, then you can press VO + left to move the VO cursor through the listitem's content.

In Chrome:
When the system focus in on an ARIA listitem the VO cursor remains on the top-level ARIA lis, will get stuck on an anchor within a listitem, or track behind the listitem with system focus.

So, there you have it. This one feels like a bug to me. The good news is for our use case within Slack, we're already planning to add an aria-label to each listitem, so we can resolve this issue independent of a fix from the Chrome team. But, I still think this should be addressed.

Let me know if you disagree or require more info.

Todd

Thanks!

The reason I suspect aria-label makes a difference is because then we expose the text in AXDescription instead of AXTitle, indicating it's accessible text and not user-visible text. That forces VoiceOver to ignore the subtree and just use the provided text, treating that object as an atomic unit.

That said, if there's a concrete difference between Safari and Chrome without aria-label, we should figure out what it is and fix it.

Great! Thanks Dominic