the real issue here is that since we don't actually render this as markdown, SR users don't hear that they're on a link at all.

root cause issue: #211657

perhaps we should just have a command which shows a quickpick with the commands that will jump to the keybindings editor for that command ID?

@jooyoungseo and @rperez030 with your focus in the GHPR issues/ pull requests view, if you open the accessibility help dialog, there are links of the format:

-GitHub Pull Requests: Create Pull Request [Configure a keybinding](command:workbench.action.openGlobalKeybindings?%22pr.create%22)

When your cursor is within the (command:) part, ctrlCmd+enter will run that command.

I realize this is not discoverable ATM.

A few questions:

1. any idea how we could make it discoverable?
2. is the syntax too verbose / annoying given the full URI is provided such that we should rethink this?

My alternative idea would be to have a quick pick that one can access from the accessible view to set the keybindings for any commands that lack them.

There is something that @ramoncorominas discovered and shared with me some time ago. When the cursor is in the accessibility help dialog, if I press CTRL +Shift +V, the content will be rendered as markdown, which means that screen readers will see it as rich text format and all the links and structural elements become accessible. I don't think this functionality is intentional, which means that, after doing that, there is no good way to return to whatever I was doing. I believe having a supported way to render that content as markdown could solve this problem and add additional value.

Having a quick pick is also a good idea in my opinion, but doesn't resolve the discoverability issue because one still have to know to activate that, and I agree that presenting the full URI would be extremely annoying, and potentially incomprehensible for some.

Woah, I was not aware of that trick 🤯 . I wonder if toggling between markdown preview and the text document in the accessible view would be a good solution. That trick atm opens an editor tab, which as you said, doesn't allow you to go back to the accessible view.

Toggling to the preview version with ctrl+shift+v will have the same discoverability issue. Also, links don't work there because of this error:

Error: Unable to resolve filesystem provider with relative file path 'accessible-view:accessible-view-pr:github#

@mjbvz it seems the editor has to be in the filesystem for this to work. could we change that? secondly, it would be better if we could provide the URI of the accessible view and render the preview there rather than in a new editor tab. do you think that would be possible?

Re discoverability, whether we go with this preview idea (and fix the link issue) or provide the quick pick with commands that lack keybindings (and remove the links), we should provide shortcut in the accessibility help dialog for the accessible view.

Actually, the quick pick is the better approach IMO. I'm indicating how to open that via keybinding in the accessibility help dialog content, so it seems discoverable. Will appreciate your testing of this soon @rperez030. Thanks so much for the feedback.