Extensions with Orca: pressing enter does not properly pass focus to details

[jvesouza]

Issue Type: Bug

1. Launch orca.
2. Launch VSCode.
3. Press ctrl + shift + x.
4. Choose an extension using the arrows.
5. Press the enter key.
6. Try navigating using the arrows.

In my environment what is read by the orca does not represent the details of the extension.
To access the contents of the extension details, I need to press the digit 1 after pressing the enter key in the list of extensions.
The digit 1 is mapped in orca to the command goes to next heading at level 1.

CC @isidorn
VS Code version: Code - Insiders 1.44.0-insider (6cf3dd9, 2020-03-27T05:34:30.255Z)
OS version: Linux x64 5.5.13-arch1-1

[isidorn]

@jvesouza thanks for filling this issue.
Yes I can reproduce this, but only when I turn on Orca. Without Orca the focus is properly passed on to the Extensions Details page.
I believe the issue is that Orca jumps in and changes the focus behavior. Thus also pinging @joanmarie to get her feedback.
Please note that we have changed the role of the extnesions details page to be docuemnt based on this feedback #93087
So I believe due to some interactions of roles Orca behaves strange with regards to respecting focus.

[joanmarie]

If the role is document, Orca might be treating it like a newly-loaded document and putting focus at the top of the page. But lemme investigate.

[joanmarie]

Related aside: When I press the enter key, I start getting events from a nested document named "Virtual Document". Is that really the desired name for this object??

[joanmarie]

(Edited quite a bit because I'm finding different extensions have different content in the associated scrollable information.)

I just committed a change which I believe is doing the right thing based on what happens when Orca is not being used. But it may not necessarily be what @jvesouza thinks is the right thing. Let me explain:

When Orca is not running, and I perform the steps in the opening report, what happens at step 6 is the child document scrolls because the child document has focus. There is a parent document which has additional information such as the author, number of downloads, an install button, etc.)

Not surprisingly, when I press Enter, I see an accessibility event for the child document.

With the above background in mind, the change I made to Orca is this: Whenever we get a focus event for a descendant in a web app, trust that event and update the focus in Orca. As a result, what Orca master now does (at least for me) when Enter is pressed is move to the top of the child document and switch to browse mode making the document readable. I believe this is the right thing to do based on how VSCode works without Orca running.

What's not clear to me is if the right place for reading to begin is in this scrollable container. Should Orca instead begin its presentation at the top, including the author and number of ratings?

If Orca should move to that containing document, then I believe VSCode should grab focus on it and not the child scrollable document.

Make sense??

Lastly, I noticed there is a tiny bit of chattiness (Orca announcing "document web" a couple of times). I'll clean that up next. But I wanted to land the main change for @jvesouza et al. to test and comment on my observations above.

Thanks!

[jvesouza]

@joanmarie It was in my opinion perfect. When I press the enter key the focus jumps to the beginning of the document and I can use the arrows or the command speaks entire document to read.
Thanks.

[isidorn]

@joanmarie makes perfect sense and thank you for the explanation. I do agree if we want the author and that stuff read, VS Code should place focus there. For now let's leave it like it is and also @jvesouza seems to approve of the current behavior. Thus closing this issue. Thanks!