Tree view example

[scottaohara]

Is the intent of this example to demonstrate that someone could use this toggle behavior and get the expected semantics and behavior (specific keyboard keys and allowance for potential for some nested interactive elements) of a tree view?

Presently the behavior is similar the previous accordion/disclosure pattern, but for the fact this has retained the list semantics as nested button elements are used instead of overwriting the structural semantics like in the previous demo.

[jerivas]

The main goal is to showcase that with a single rule you can create toggle roots for nested elements and they will work independently. I prefer the usage of explicit buttons here instead of triggering directly on the lis.

[scottaohara]

hi @jerivas. thanks for the background. I'll reframe my question though. Being labelled a 'tree view' I would have expected one of two things:

1. this is only demonstrating that CSS toggles can be used to show/hide content similarly to a tree view, but otherwise there are absolutely no expected roles/states/properties or other keyboard behavior that would actually have this be communicated as / behave like an actual treeview. It would be completely on web authors to still do all those things, and the only thing they should assume to get from this is the show/hide functionality.
2. this is meant to be a demo to represent a true treeview and all the necessary roles/states/properties and keyboard behavior are meant to be demonstrated here as well, as the intent for the CSS toggle would be that this behavior would all come with it, somehow.

it's unclear to me at this point the scope of what these demos are trying to represent. is it simply show/hide behaviors and then an author is on the hook to do everything else. Or are the demos not accurately demonstrating the expected accessibility semantics/keyboard functionality that their labelling indicates they are meant to?

i hope that helps clarify where i'm coming from here (and with my other issues). thanks

[jerivas]

this is only demonstrating that CSS toggles can be used to show/hide content similarly to a tree view, but otherwise there are absolutely no expected roles/states/properties or other keyboard behavior [...]

I'd lean towards this option but will let @mirisuzanne clarify

[mirisuzanne]

Hi @scottaohara - thanks for all your great comments here! The overall goal of CSS Toggles is to get to the point where authors don't need to handle all the aria roles by hand (your option 2), but we know we're not there yet. So far this is a demo of the current state of the spec, as best we can reproduce it, and a place to document/explore the problems that still need to be solved (like this one). So the goal at this point has been to surface exactly these questions, and then work through it from a few angles:

• would extra syntax be required in order to know what roles should be used, or can we infer those answers from existing syntax and how it's used?
• how does that impact the proposed CSS specification?
• can we improve the concept here in a polyfill, or would it require browser internals?

Thanks for filing the issue, I'll add a link to it from the demo page - and document it in the Toggles explainer as well.

/cc @tabatkins

[scottaohara]

thanks @mirisuzanne, that explanation does help. So the polyfill is not to demonstrate the ideal end state at this point, but rather there are supposed to be accessibility issues with these widgets, and the demo is to illustrate and thus elicit feedback on what these would need to behave like?

[mirisuzanne]

@scottaohara Yeah, that's roughly the current state. I can work on documenting that better with some warnings. I think it would be great if we are able to resolve some of those issues here in the polyfill, and that would be a great next step here – but I expect some of these issues will require broader changes to the spec itself, and we'll want to open issues on that repo as well.

(Still trying to figure out the best place for each of these things to live - as we're a bit scattered between the spec, this polyfill, and the various potentially interested w3c working/community groups).

[scottaohara]

if you want a review of the updated documentation/warnings, or if i can help, please let me know.