Extend allowed roles for content of groups in treeitem

[stes-acc]

The chapter about treeitems in ARIA spec defines the groups as owned elements to contain ONLY treeitems.

In reality, there a lots of examples where those groups (solely to be used as "leaves") do contain other non-presentational elements like links and buttons together with presentational content (text, images) etc.

Using Treegrid is NOT the answer here since these trees typically lack a column-like layout.

Attempts to create more interactive tree views like this example ASP.net project show also the need for scenarios where text boxes for node editing are part of the (editable) tree.

The requirement therefore would be to extend the types of allowed group members, the challenge is to have a keyboard navigation among those consistent to the one already existing in the tree model.

[mcking65]

@stes-acc

Can you explain how such a tree would be functionally different from a tree grid? Tree grid does not require elements to be layed out in columns. And, in cases where they are not, we could simply extend the tree grid model/pattern for trees that have one cell per row and a bunch of interactive elements inside that cell. Or, in cases like the one you site, perhaps there are two cells, and each have multiple interactive elements.

One of the approaches that has been suggested for the current tree grid (and potentially grid patterns) is that all interactive elements in a row are in the tab sequence instead of just one. This would help address concerns with elements like text inputs. It would require using tab to focus the entire row to navigate the tree.

Net, I don't understand what the difference would be between a treeitem that acts like a container and the current gridcell role, especially when you look at from the accessibility API in the way that an AT would. From the AT perspective, it seems like treeitem would then become a very confusing entity.

[stes-acc]

Can you explain how such a tree would be functionally different from a tree grid?

Sure. Treegrid without extensions will have always focusable empty cells as part of the ARIA 1.0 x/y scheme. Tree has not. This goes deep. Of course you can use colspans to "mimic" that.

Tree grid does not require elements to be layed out in columns.

From the name already I expect x/y row/column layout. And AT too. A grid without columns would even be more confusing.

As a side comment:
Grid examples like in 1.1 APG show the focus either being on a grid cell or on the content which is masking the fact that for a straight consistent experience it has to be finally decided that ONE location should be used (focus on grid cell preferred), not to speak of the sad fact that AT is not looking INSIDE a gridcell on focus which automatically raises the need to focus the interior. I would be also OK with a paradigm that always focuses the interior and NOT the cell itself BUT THEN you have the issue that all automatic relations of cell to headers and position info won't be read automatically because AT is just not looking one level up on focus so you have to add these relations manually AGAIN to the focused element ending up in declaring relations both for cell AND content which doubles required coding. We have a similar lookup/down discussion for aria-sort in headers. Frankly, things like these have to be resolved first before I recommend grid and treegrid patterns wholeheartedly to devs.

all interactive elements in a row are in the tab sequence instead of just one.

In our data grids, we use arrow navigation to focus every cell and F2 or SPACE enters the cell for editing. The model can be easily extended to hold entire groups of controls in a single cell that are then navigated by TAB. Use cases for this are for instance different input elements to enter parts of ID numbers.
TAB is used for entering/exiting the data grid and to switch between header rows and data rows. Once a cell content is focused, TAB works different in the sense that it focuses now all interactive content in next/previous cells. This is a very robust pattern and works reliably.

Net, it is a much cleaner approach if we allow defined groups in other role entities like gridcell and treeitem. I agree that if we do this, we need additional AT signaling to avoid confusion. This could be done using specialized roles ("gridcellgroup", "treeitemgroup"), by adding containers with specialized group role or by additional properties or descriptions being part of the cell with grouped content. But there must be at least SOME signaling that a cell contains multiple content, otherwise the quick orientation will suffer.

[jnurthen]

@stes-acc please also search for other similar issues that may have been discussed in the past

[jnurthen]

sounds like #1440 will resolve this so closing