Improve discoverability of accessibility verbosity settings

[meganrogge]

I imagine the accessible view hints (and others) that we have around the workbench are annoying if a user doesn't know they can be disabled. Should we include info about disabling at the end of the hint?

For example, "Use Tab+Shift to access the terminal accessible buffer, disable this hint with the accessibility.verbosity.terminal setting

cc @jooyoungseo, @rperez030

Someone just emailed me that they didn't know where this was coming from and were annoyed by it.

[jooyoungseo]

@meganrogge Didn't we include the option like pressing "D" to disable it? Where did it go?

[meganrogge]

Yes, when a user is in the accessibility help menu they have that option.

What I am referring to is when you focus a chat response (with accessibility.verbosity.panelChat enabled), you hear the response then "Inspect this in the accessible view with keybinding"

[meganrogge]

Ideally instead, we could have an audio cue to indicate this. Such that when you focus an item and it has an accessible view provider registered, you hear the cue.

[jooyoungseo]

@meganrogge -- Audio cue may not a good choice when it requires a user action because it assumes users have prior knowledge on how to trigger the expected action.

[jooyoungseo]

@meganrogge -- Rather than giving users the specific setting pointer, could we add any key bindings to disable the message? "[hint message ...] to disable this hint message, press [key]"

[meganrogge]

the way I implemented this in the linked PR, a user will have to open the accessible view to hear how to disable that hint. maybe that's for the best as we don't want a user to disable it and then never know there's a nice way to view the element. we can discuss

[rperez030]

I would like to suggest a different approach. To me, the real problem is having all of these hints attached to the accessible labels for controls. The hint should be provided only once via an alert when a relevant UI receives focus. For example, upon setting focus in the terminal for the first time, I get an alert telling me to press Alt +F1 for help using the terminal with a screen reader. I won't receive this hint again until I restart the editor or move focus to a new UI that supports accessibility help, and I can disable it permanently in settings. In the accessibility help, I will learn all the keyboard commands I need to know about, including how to disable accessibility hints. I can always go back to accessibility help if I forget something, and maybe I can enable / disable hints from there directly by pressing D. Some keystrokes like Shift +Tab to move to the accessible buffer would be very difficult not to remember because they make a lot of sense. Others, like Alt +f2, maybe not so much. It still may be necessary to advertise the presence of accessible view for chat responses, tooltips and so on since this is not available everywhere. for that, a very short message such as 'Accessible view available' at the end of the string in combination with a configurable audio cue. I may end up disabling the hint and keeping the audio cue until accessible view becomes so ubiquitous that I don't need to be told about it anymore. there is precedent for that way of advertising accessibility in voiceover custom actions, for example.

What do you both think?

[meganrogge]

@rperez030 Thanks for your thoughts. I agree that we should move this out of the aria labels.

JooYoung and I discussed that perhaps when we have #189486, we can add buttons that can be discovered via tab for things like disable verbosity hint, go to symbol, etc. That way we wouldn't need users to open the accessibility help menu right when they open an accessible view to discover features/commands.

[meganrogge]

We now indicate that the hint can be disabled in the aria label of the accessibility help dialog. Verify that you hear this upon opening that and that when you disable verbosity, you no longer hear that hint.

[joyceerhl]

I cannot seem to get the accessibilty help dialog to appear for a notebook. This is what I see when I enable keyboard shortcut troubleshooting

2023-08-29 10:58:40.309 [info] [KeybindingService]: | Resolving alt+F1
2023-08-29 10:58:40.309 [info] [KeybindingService]: \ From 1 keybinding entries, matched editor.action.accessibilityHelp, when: no when condition, source: built-in.
2023-08-29 10:58:40.310 [trace] KeybindingService#dispatch Alt+F1 [ Will dispatch command editor.action.accessibilityHelp ]
2023-08-29 10:58:40.310 [info] [KeybindingService]: + Invoking command editor.action.accessibilityHelp.
2023-08-29 10:58:40.310 [trace] CommandService#executeCommand editor.action.accessibilityHelp
2023-08-29 10:58:40.311 [trace] Executing Command 'editor.action.accessibilityHelp' which has 16 bound.
2023-08-29 10:58:40.311 [trace] Command 'editor.action.accessibilityHelp' was handled by 'notebook'.
2023-08-29 10:58:40.552 [info] [KeybindingService]: + Ignoring single modifier alt due to it being pressed together with other keys.

I have not disabled accessibility features, using Windows Narrator

[meganrogge]

@joyceerhl what are you focusing when you invoke it?

[joyceerhl]

Aha, I had a markdown cell in preview mode focused. This one: https://insiders.vscode.dev/github/microsoft/vscode/blob/main/.vscode/notebooks/my-endgame.github-issues#C6:L1

Seems like an actual bug (if I focus a code cell I get the help view), I will file a new issue