No longer possible to tab between the SharpTreeView and AvalonEdit components

[glenrgordon]

My intent was to fix the issue and submit a pull request, but after spending several hours trying to diagnose what's going on, I came away stumped. Hoping that you can devote a little time to investigating this.
As a screen reader user, the inability to tab between these two components makes using relatively recent ILSpy versions nearly impossible.
I was the one who added improved accessibility support to SharpTreeView and Avalon edit back in 2014. The UI seemed simpler back then.

[dgrunwald]

ILSpy is now using AvalonDock for multi-document support.
Switching tabs with the keyboard apparently requires Ctrl+Tab (as in VS) but the UI for that seems to be quite broken.

[siegfriedpammer]

I will take a look why the NavigatorWindow behaves strange. Taking a look at https://github.com/Dirkster99/AvalonDock no such issue was reported before.

[glenrgordon]

Thanks to both of you for taking an interest in this issue.

[siegfriedpammer]

@glenrgordon The issue should be fixed in the latest nightly build, you can get it from here. If you face any other problems when using ILSpy, please open an issue and we'll take a look. Thank you very much!

[glenrgordon]

Sadly, this didn’t fix the problem I’m currently facing. Back in the old days before ILSpy used AvalonDock, I was able to tab from an item in the TreeView to the disassembly of that item, and then shift tab back to the item in the tree. Life was good and very accessible. With this change, I expected that Ctrl+Tab would let me do the same thing that tab used to do. When I hold down Ctrl and repeatedly press tab, focus alternately moves to the list of files and then to the list of tool windows but the active item in the list isn’t changed. I’d expect this to work like Visual Studio where repeatedly pressing tab while holding down Ctrl would move between the items in the files list followed by the items in the Tools list, so that when Ctrl is finally release, focus will move to the corresponding item that was active in the list. As things currently stand, I don’t think I can use the keyboard to move from an item in the tree to its disassembly in AvalonEdit or move back to the tree from the disassembly. If I am misunderstanding the way things now work, please let me know.

[siegfriedpammer]

OK, I think I see the problem you are facing:

• If you want to switch from AvalonEdit to the TreeView you actually have to press Tab twice while holding down Ctrl: once to open the switch dialog window and another time to change the selection from AvalonEdit to the TreeView, when you release the keys, the dialog closes and the focus change is applied.
• If you want to switch from the TreeView to AvalonEdit you only have to press Ctrl and Tab once, because the initially selected item is always the document (i.e., AvalonEdit).

@glenrgordon Is my analysis correct?

The behavior in VS is as follows:

1. one key-press of Tab (while holding down Ctrl) immediately changes from the currently selected document to the next one.
   • that is, if the focus is currently applied to document;
   • if the focus is on a tool window, one key-press of ctrl+tab opens the dialog and places the initial selection on the document.
2. to switch between documents (AvalonEdit) and pads (TreeView) you actually have to use the arrow keys, because Ctrl+Tab only cycles the documents

So, the ideal behavior of AvalonDock (for ILSpy) would be: (@Dirkster99 please add your thoughts, because I am going to provide a pull request with the changes, once we've agreed upon a solution, thanks!)

1. Cycle all items (not just in the group of documents or tool windows separately) - which is currently the case with AvalonDock
   (note: VS behaves differently, the arrow keys are required to switch to the list of tool windows)
2. The initial key-press moves to the next document/tool window (if there is more than one) - my previous fix actually breaks this, because I set the selection to the first document/tool window.
3. If there is only one document, we move to the first tool window - this works already, but only by pressing twice, because the focus is always returned to the first document currently.
4. The starting point of cycling should be the item that is currently focused - currently it's always the first document (tool windows are only considered, if there is no document, which is impossible in the case of ILSpy)

So the necessary changes:

• Move the focus to the next item on the first Ctrl+Tab press
• Consider the currently active type of content, when selecting the next item

@Dirkster99 would you accept a pull request implementing this behavior as default? The first change restores the correct behavior for multi-document use-cases. The second change would only be useful for ILSpy. As the tool window/document switching behavior was already different from VS, I would not see this as a problem and it would only be different if there is only one active document. Not sure, if the other users of AvalonDock would mind such a breaking change? Thank you for your feedback!

@glenrgordon Note, I haven't tried using Narrator with ILSpy/the switching dialog window yet. Does it work as you would expect? Thank you!

[glenrgordon]

When I tested yesterday, no matter how many times I pressed tab while holding down the Ctrl key, I couldn’t move keyboard focus inside AvalonEdit. But when I tested again today, I first used accessibility utilities built into the JAWS Screen reader to force focus into AvalonEdit so I could read the disassembly. From that point forward, I could successfully use Ctrl+tab to move between the tree and the disassembly: once to get from the tree to the disassembly and twice to get back to the tree. The above makes me think that when first launched, logical focus in the tab containing AvalonEdit isn’t actually on AvalonEdit but is on the tab or something else. Once logical focus is forced there, Ctrl+tab will allow moving back. Does this seem reasonable? On a related topic, when holding down Ctrl and then pressing Tab, JAWS thinks that the focus is either on the list of documents or list of tool windows. It would be ideal if focus could actually move to the list item containing the name of the document or tool that will actually get focus when releasing the keys. Thanks for spending so much time on this issue.

[Dirkster99]

@siegfriedpammer
@glenrgordon

Hi Guys

Move the focus to the next item on the first Ctrl+Tab press

is fine with me since the user is most likely to use Ctrl+Tab to change to another document rather than a tool window (That's at least the underlying assumption of Ctrl+Tab in Visual Studio and I would argument that most AvalonDock Apps are document oriented in the same way).

Now I am not sure what you mean by:
'Consider the currently active type of content, when selecting the next item'

If this means you want to tab to the next Tool Window when the previously selected item was a Tool Window then I would agree that it would break the expected document centered behavior. Maybe we could make this either:

1. an optional tabbing behavior - leaving the default as it is right now (always tabbing to a document first) but add an option to tab to another tool window if the last item was a tool window

or

2. change the tabbing behavior to align with the cursor implementation of VS?

... but I admit 2) does not really help you since you seem to have an interest to tab from Tool Window to Tool Window rather than assuming with priority to a document - so, 1) seems to be a better option and might also be interesting for other Apps because I know there are even AvalonDock Apps out there that have no document at all - what do you think about these options?

[glenrgordon]

I’d be thrilled with starting from the currently active document and cycling ignoring tool windows. For a screen reader user, a much better tool window solution is to have hot keys for bringing them up on demand rather than needing to repeatedly press Ctrl+tab to get to the right one.

[siegfriedpammer]

@Dirkster99 Thanks for your response. So, if @glenrgordon is fine with the VS behavior, I can provide a PR that changes the NavigatorWindow behaviour to work exactly as in VS, including our single document scenario.

This would mean that, we'd have to introduce shortcuts for our tool windows. @glenrgordon are you fine with having to use two different shortcuts to switch from documents to the treeview?

[glenrgordon]

What would you think of f6 as a hot key for toggling focus between the tree and the currently active document. When focused on a document, Ctrl+tab would allow switching to a different one? Assuming I’m properly understanding the ILSpy UI paradigm, this would be a great solution from an accessibility standpoint.

[siegfriedpammer]

What would you think of f6 as a hot key for toggling focus between the tree and the currently active document. When focused on a document, Ctrl+tab would allow switching to a different one? Assuming I’m properly understanding the ILSpy UI paradigm, this would be a great solution from an accessibility standpoint.

The latest release of ILSpy (7.2.1) uses F6 as hotkey for the "Assemblies" pad, Ctrl+Shift+F for the "Search" pad and Ctrl+R for the "Analyze" pad. As far as I can see, switching between multiple tabs and pads using Ctrl+Tab now works (almost?) exactly the same as in VS 2022. The Ctrl+Tab switcher window is now understood correctly by the Windows 10 built-in screen reader "Narrator".

@glenrgordon I hope that ILSpy is now usable via a screen reader. If there are any other bugs, please feel free to open another issue and I'll be glad to make further improvements.

[glenrgordon]

Let me first express profound thanks for devoting time to accessibility issues. I know that there’s lots to do on this project and the fact that you spent time in this area is much appreciated. There is one issue that remains: if keyboard focus has never been on the ICSharpCode.AvalonEdit.TextEditor of a particular tab, then pressing Ctrl+Tab from the Assemblies Pad will not move keyboard focus to the TextEditor when Ctrl+Tab is released to move focus to that tab. If, however, one is able to get focus into the TextEditor in some other way so that arrowing around within the disassembly actually moves the caret, then after pressing F6 to get to the Assemblies Pad, Ctrl+Tab when release will put focus back inside the TextEdditor so that a screen reader user can use the arrow keys to move around and read the disassembly. What is really needed is for keyboard focus to always be on the TextEditor after using Ctrl+Tab to focus a disassembly document tab. From: Siegfried Pammer ***@***.***> Sent: Monday, April 4, 2022 1:46 PM To: icsharpcode/ILSpy ***@***.***> Cc: glenrgordon ***@***.***>; Mention ***@***.***> Subject: Re: [icsharpcode/ILSpy] No longer possible to tab between the SharpTreeView and AvalonEdit components (Issue #2577) What would you think of f6 as a hot key for toggling focus between the tree and the currently active document. When focused on a document, Ctrl+tab would allow switching to a different one? Assuming I’m properly understanding the ILSpy UI paradigm, this would be a great solution from an accessibility standpoint. The latest release of ILSpy (7.2.1) uses F6 as hotkey for the "Assemblies" pad, Ctrl+Shift+F for the "Search" pad and Ctrl+R for the "Analyze" pad. As far as I can see, switching between multiple tabs and pads using Ctrl+Tab now works (almost?) exactly the same as in VS 2022. The Ctrl+Tab switcher window is now understood correctly by the Windows 10 built-in screen reader "Narrator". @glenrgordon <https://github.com/glenrgordon> I hope that ILSpy is now usable via a screen reader. If there are any other bugs, please feel free to open another issue and I'll be glad to make further improvements. — Reply to this email directly, view it on GitHub <#2577 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEMY6EIXVSTSUY3LJ7A2OIDVDM2F3ANCNFSM5J3JLV6Q> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AEMY6EIFT33VHJX3OY4TZ73VDM2F3A5CNFSM5J3JLV62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIDL67XQ.gif> Message ID: ***@***.*** ***@***.***> >