[Question] Can treegrids have different column headings for child rows?

[mgr34]

The treegrid example has repeating column headers [0]. What if when the hierarchical content is expanded it has new shape with different column headers? Should a new treegrid be declared? Are nested treegrids advisable?

If nested treegrids are advisable, can we nest something else like a layout grid [1]?

[0] https://www.w3.org/WAI/ARIA/apg/patterns/treegrid/examples/treegrid-1/#ex_label
[1] https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/layout-grids/#ex3_label)

---

Edit: I have an additional question about treegrids. Should I keep them in this issue, or open a new one. My other question:

• What about focus-able <thead/> or <tfoot/> content?
  • For example, there maybe a leading checkbox in each row. Wherein the checkbox in the thead selects all visible rows and their descendants. Should this be focus-able before the rows in <tbody/>?
  • Similarly, content in the foot such as pagination options, should that be focus-able using the Arrow Keys, or should the user need to Tab to that content?

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Issue 2806: Must all treegrid rows have the same columns?.

The full IRC log of that discussion

<jugglinmike> Topic: Issue 2806: Must all treegrid rows have the same columns?
<jugglinmike> github: https://github.com//issues/2806
<jugglinmike> Jem: the question is: Can treegrids have different column headings for child rows?
<jugglinmike> Matt_King: My gut reaction was "is course, all rows have to have exactly the same columns"
<jugglinmike> Matt_King: When I read the spec, and when I think about tree grids, for me, the notion of different columns sounds much too complicated to ever be useful
<jugglinmike> Matt_King: But then I thought about how many business applications do very complicated things, so I want to leave the door open to the possibility
<jugglinmike> Matt_King: And to be clear: I couldn't find anything in the spec that explicitly forbids this
<jugglinmike> Matt_King: It's not clear to me that treegrid is exactly one tree and exactly one tree merged together
<jugglinmike> CurtBellew: When I hear this, I imagine a "more detail" row which can be expanded and collapsed. That's the only use case I can think of
<jugglinmike> CurtBellew: Basically, it nested that one row. I can't remember exactly how the example I saw worked, but it was definitely difficult to use
<jugglinmike> CurtBellew: I wonder if what they're aiming at here is more like that--a parent with a child which holds additional details
<jugglinmike> CurtBellew: A lot of the time, in my experience, this is about nesting tables, which is always a big mess
<jugglinmike> CurtBellew: Usually, for us, it's system status. You have a list of systems. One row might describe a database that's either "up" or "down", and you can expand that to see more diagnostic information
<jugglinmike> CurtBellew: But that's only the closest thing I can think of. I'm not sure it really matches what's being described
<jugglinmike> Matt_King: I've never found a screen reader that handles nested tables gracefully
<jugglinmike> CurtBellew: It wreaks havoc with our internals checkers
<jugglinmike> Matt_King: We might want to ask for specific use cases which justify this
<jugglinmike> Matt_King: Even though our initial thought is that this is somewhat contradictory to a grid. That a grid is not a grid unless it has consistency between all rows. And that a tree grid is a grid, so that principle still applies
<jugglinmike> Andrea_Cardona: one person on the Carbon team focuses on the tree grid implementation
<jugglinmike> Andrea_Cardona: I haven't personally seen an example of this, but I haven't worked with our Tree Grid very much
<jugglinmike> CurtBellew: I would love to see some way to do something similar because we have some cases where something like this would be useful

[JAWS-test]

What if when the hierarchical content is expanded it has new shape with different column headers?

Even if this were possible, it should be avoided because it leads to a structure that is difficult to understand

Should a new treegrid be declared?

If no new column headings are possible within the treegrid, then this would be the only possibility. However, I can theoretically imagine that new column headings are defined within the treegrid. But as I said: better not.

Are nested treegrids advisable?

This is definitely not recommended. Treegrids are already difficult to use and understand. A nested treegrid is a nightmare. Please consider the following alternative: A button in the treegrid opens a detail view (in a pop-up, on a new page, below the treegrid) and sets the focus to this detail view. A back button can be used to return to the treegrid.

[JAWS-test]

What about focus-able thead or tfoot content?

For grid and treegrid applies

Only one of the focusable elements contained by the grid is included in the page tab sequence

I.e. all other cells or rows receive focus only with the arrow keys. This also applies to elements in thead or tfoot.

The pagination should not be part of the grid or treegrid, but should be in front of or behind it, as the pagination has no table structure. The pagination is thus reached via TAB key.

The checkbox for selecting all elements can be located in the column header and can only be reached with the arrow keys.