Treegrid has out-of-the-box keyboard navigation, but it seems a bit weird:
Arrow-right opens opens a parent. That’s fine
Arrow-right again does "something; I can see the focus ring moving slightly
Now I have to do Arrow-left twice to close the parent
The effect is that it looks like arrow-navigation is broken sometimes.
Arrow-left on a child does the same “something” as on parent
Arrow-right on child does nothing useful. It should’ve moved up to parent
Is there a way for me to fix that, so that Arrow-left on child moves up to parent?
It would mean setting the focus, not selection, so not sure how it should be done
When this happens, one needs to use arrow-left twice to collapse the item, as the first arrow-left will move the focus from the cell to the row, where the item can be collapsed/expanded.
Now, it should be clear that the focus has changed, as seen in the picture, which makes me wonder why the focus ring moves slightly in your case.
The tactile feel of the TreeGrid keyboard navigation is very un-intuitive and poor. I was searching our tickets and noticed that I have not yet created an issue about this, although I recall having some internal discussions. Perhaps I have just been too busy. My own experience comes from creation of Tree add-on
Which is basically just one column TreeGrid, and the shortcomings of the TreeGrid keyboard navigation becomes more pronounced in this case.
Furthermore I made TreeComboBox TreeComboBox - Vaadin Add-on Directory Which otherwise works very nicely, but when using Tree in Popup that is part of the field, you would appreciate well working keyboard navigation.
The current behavior of TreeGrid mostly follows the keyboard interactions defined in the ARIA Authoring Practices Guide: Treegrid Pattern | APG | WAI | W3C
Right Arrow:
If focus is on a collapsed row, expands the row.
If focus is on an expanded row or is on a row that does not have child rows, moves focus to the first cell in the row.
Left Arrow:
If focus is on an expanded row, collapses the row.
If focus is on the first cell in a row and row focus is supported, moves focus to the row.
If a (tree)grid is a problem for accessibility we have bigger problems…
We will probably have a look at the Side Navigation at some point. It looks nice, but it remains to be seen how it scales. We have hundreds of entries in the menu, and a few instances of multiple levels.
We also have a filter above the treegrid, which can use the built-in filtering mechanism of the TreeDataProvider. With Side Navigation I would have to loop over filter the Vaadin components themselves and set hidden/visible. We already do that in other places, but it seems less clean.
Looking at Side Navigation now, I notice that it does not support arrow navigation, only tab / shift-tab. I don’t know what is expected for accessibility, but for my own use I find that to be a regression.
Click on the example app. It has one more rule:
Left Arrow: If a row is focused, and it is collapsed, moves to the parent row (if there is one).
Please note that such a rule is not listed in the treegrid keyboard interactions linked above but it’s rather a feature in the example treegrid as mentioned on the page.
Not to say this wouldn’t be a nice addition to Vaadin TreeGrid also.
I just added a Shortcuts.addShortcutListener to my TreeGrid for Enter to “click” the row.
It worked, but after using left/right arrow to collapse/expand a section it stopped working.
I googled, found this thread, and was surprised to see that it was started by me 5 months ago
So, keyboard navigation in (single column) TreeGrid is still not very good in 24.5.0, and the issue @Tatu2 registed is untouched.
I ended up creating customized toggle in my Tree add-on that overrides TreeGrid default keyboard navigation.
I later noticed that my approach there is a bit non-standard as I did not add cursor left/right … Which is in my TODO list to add there. It is straightforward in my case as in Tree there is only one column.
In TreeGrid the case is more difficult as cursor left/right should browse cells, so there is conflict here. So in TreeGrid one should either do it like in Tree now. Or use cursor left/right to toggle expand collapse and use tab / shift+tab browse cells. And either way you do it, you are slightly breaking conventions and backwards compatibility and before users adapt the change you will get some irritated feedback first.
I do agree with that, but it does break down for the 1-column case.
I had another look at Treegrid Pattern | APG | WAI | W3C and they do seem to acknowledge that in some cases a row-only mode makes sense:
Note: A row-only option is not provided. A treegrid where cells cannot be focused would be implemented as a tree view. A treeview that has columns in its visual presentation may be appropriate when all the following conditions are present:
Columns are guaranteed to fit horizontally (no horizontal scrolling necessary).
Columns are merely for attractive presentation; there is no need to navigate them individually.
A screen reader user can easily understand the UI when all information in a row is announced as a single string without any separation.
Based on this I would suggest that Grid and TreeGrid should allow me to enable row-mode
The row focus mode do exists in Grid/TreeGrid. But it is not mentioned here: Grid | Components | Vaadin Docs
It is a quite new feature.
E.g. with TreeGrid, if you press cursor left when you are on the first column it will toggle from cell focus mode to row focus mode. After that next cursor left will collapse the tree or right will expand. If the row is expanded and you press right again, it will go back to cell focus mode.
What I read out of Treegrid Pattern | APG | WAI | W3C is that in some cases it is acceptable to not have a cell focus mode. Either because there is only one column, or because the other columns are decorative and there is no value in navigating to them.
tldr:
There is no value in distinguishing between row and cell in a 1-column grid.
You are not required to do so for accessibility. You are free to make it not suck
Yes, such mode would be much more pleasant to use than how it works now. That was my motivation in doing the custom solution in Tree as there the current way of working is way too superfluous. Furthermore the Tree component is used in TreeComboBox, so in order to make that one work in somewhat accessible manner, I needed it. There it is even more relevant.