Apologies for the long time taken to actually post the reply, Nicolas! These are my thoughts on the questions asked: ### Selected vs Active frame (here and below the quotes are in reply to Nicolas Chevobbe [:nchevobbe] from comment #3) > a dead frame can't be "active" in Debugger's semantics. Clicking on it will only navigate the editor to the location it points to... This would still be `active` UI for the accessibility. It sounds like it's functioning as a link that would navigate a user to the other place (like a number control in an elevator) vs a button that a not "dead" frame would function as (like a close/open doors or call assistance control in an elevator) > Also, since those frames can't be "active", should we have some kind of label on them to indicate they're different? marking these "dead" frames as links (maybe dynamically adding `role=link` to reassign the programmatic role would work as a hacky way to avoid rewriting more UI, since I assume these frames can become "dead" or "active" in real time or at any point after initially appearing on the page) > In the screenshot, I kept the active frame with the blue background, and for the selected one, I'm apply the same style as for focused elements. Is this okay? This looks great because it is visually apparent that these two are different states. It may not be clear from the static screenshot which one is selected and which one is active, but from the interaction with frames this should be apparent. And the selected frame is `aria-selected=true`, right? so we could also communicate it programmatically. You could also add the underline to the "dead" frame to highlight that it would function differently from the selected and active frames, that it would (only) take a user away to another location. This would ensure all 3 different states (besides the default) would have visual difference too. ### Grouped frames > Can I have the "React" item being a button that will collapse the group? First of all, thank you for the through investigation into this! The specificity of the `listbox` is that is does not allow anything that is not an `option` or a `group` with `option` children to be its direct children. This is why there are no examples. And while not having examples is something that we can craft our way over, [the ARIA specs limitations](https://w3c.github.io/aria/#listbox) described above are something that may prevent proper work with the component by an assistive technology. That's being said, we could use `list` or `<ul>` as a parent to include all the disclosure buttons (with `aria-expanded` property) as `listitem` or `<li>`, and each list item could also include its own `listbox`. Or maybe we could use [Treeview pattern](https://www.w3.org/WAI/ARIA/apg/patterns/treeview/) where nodes can be expanded/collapsed? In this case, there is a Treeview component that [devtools has implemented](https://searchfox.org/mozilla-central/source/devtools/client/shared/components/tree/TreeView.js) or a Bookmarks sidebar uses its other version too. LMK if you have any concerns - I'll be happy to brainstorm further
Bug 1843324 Comment 4 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Apologies for the long time taken to actually post the reply, Nicolas! These are my thoughts on the questions asked: ### Selected vs Active frame (here and below the quotes are in reply to Nicolas Chevobbe [:nchevobbe] from comment #3) > a dead frame can't be "active" in Debugger's semantics. Clicking on it will only navigate the editor to the location it points to... This would still be `active` UI for the accessibility. It sounds like it's functioning as a link that would navigate a user to the other place (like a number control in an elevator) vs a button that a not "dead" frame would function as (like a close/open doors or call assistance control in an elevator) > Also, since those frames can't be "active", should we have some kind of label on them to indicate they're different? marking these "dead" frames as links (maybe dynamically adding `role=link` to reassign the programmatic role would work as a hacky way to avoid rewriting more UI, since I assume these frames can become "dead" or "active" in real time or at any point after initially appearing on the page) > In the screenshot, I kept the active frame with the blue background, and for the selected one, I'm apply the same style as for focused elements. Is this okay? This looks great because it is visually apparent that these two are different states. It may not be clear from the static screenshot which one is selected and which one is active, but from the interaction with frames this should be apparent. And the selected frame is `aria-selected=true`, right? so we could also communicate it programmatically. You could also add the underline to the "dead" frame to highlight that it would function differently from the selected and active frames, that it would (only) take a user away to another location. This would ensure all 3 different states (besides the default) would have visual difference too. ### Grouped frames > Can I have the "React" item being a button that will collapse the group? First of all, thank you for the through investigation into this! The specificity of the `listbox` is that is does not allow anything that is not an `option` or a `group` with `option` children to be its direct children. This is why there are no examples. And while not having examples is something that we can craft our way over, [the ARIA specs limitations](https://w3c.github.io/aria/#listbox) described above are something that may prevent proper work with the component by an assistive technology. That's being said, we could use `list` or `<ul>` as a parent to include all the disclosure buttons (with `aria-expanded` property) as `listitem` or `<li>`, and each list item could also include its own `listbox`. Or maybe we could use [Treeview pattern](https://www.w3.org/WAI/ARIA/apg/patterns/treeview/) where nodes can be expanded/collapsed? In this case, there is a Treeview component that [devtools has implemented](https://searchfox.org/mozilla-central/source/devtools/client/shared/components/tree/TreeView.js) or a Bookmarks sidebar uses its other version too. [Editing to add this paragraph:] Another way could be to use [the accordion pattern](https://www.w3.org/WAI/ARIA/apg/patterns/accordion/) that relies on the button to expand/collapse a panel, and within this panel could be a listbox too LMK if you have any concerns - I'll be happy to brainstorm further