Document focus suggest details with ctrl+alt+space

[jjaeggli]

This change allows the current ctrl + alt + space shortcut perform the following action:

• When shortcut is pressed, document focus moves to the suggest details widget. This allows it to be used by screen readers.
• When arrow keys are used within the suggest widget, while details is focused, the focus indicator is removed from details, and removes the details state.
• When ctrl + alt + space is pressed when in suggest, but details is not shown, opens details

This changes the behavior in the following way:

• When moving between different items in the list, Details state is removed. This is because the details focus indicator now follows page focus. The details state allows keyboard users to navigate within long documentation using page up and page down. The user will need to re-enter the details state each time. Ie. it is not sticky.

This makes the following additional changes:

• move operations performed on the details dom to methods in suggestWidgetDetails.ts.
• adds a case statement for handling operations on state exit. Some operations could be moved here to remove duplication.
• adds button semantics to the close button

A followup to this behavior to make the suggest details widget more accessible would be to upgrade it to a modal dialog when ctrl+alt+space is pressed, allowing visual keyboard users to tab-focus to links within the markdown documentation

[jjaeggli]

@meganrogge @jrieken thanks in advance for taking a look.

[meganrogge]

Thanks very much for working on this. I will test it tomorrow.

Have you tried out the new Accessible View feature @jjaeggli? I wonder if we should also use that for the details so that SR users can inspect it char by char.

Example:

With screen reader mode on, trigger a hover and focus it. Use alt+f2 to inspect it in the accessible view. We could add support for that here too.

[jjaeggli]

Hi @meganrogge it took me some time to understand the feature, but once I did, it was easy to recognize the sound queues had associated hover information (I like the sound design also), and it seems like an easy way to reach this information. Navigating information through this dialog is as easy as navigating code, so I think it could improve usage. Our usage is primarily via Monaco - our users may not even realize that the underlying editor is vscode and so when they encounter features like suggest, we want them to be intuitive and screen reader as well as keyboard-visual friendly.

One issue I just noticed is that Monaco above v0.40 does not show the accessibility help dialog on alt + F1. This is impacting us, and is probably a somewhat serious issue for you. I'll file a monaco bug if there isn't one already.

[meganrogge]

@jjaeggli edit: tracked here, recent regression only impacting insider's #190194

[meganrogge]

ctrl+space still doesn't work for me to trigger inline suggest and thus I cannot test this change, so will have to leave it with @jrieken, but your explanation of the change above makes sense to me

[dzmitrymishyn]

Is there any progress here?
@jrieken could you please take a look at this

[jrieken]

ctrl+space still doesn't work for me to trigger inline suggest and thus I cannot test this change

@meganrogge This is not about inline suggest but about normal completions which do trigger via ctrl+space unless macOS took that to switch keyboard layouts. Uncheck those

[jrieken]

@jjaeggli Thanks for this contribution and thanks for being so patient with me. I have pushed another change on top (a simplication and wrestling some timing issus) and this is now ready to land.

[jrieken]

When ctrl + alt + space is pressed when in suggest, but details is not shown, opens details

That was the part that was senstive to timing because details show via RAF and therefore focus cannot be set immediately but only once the details have been rendered