1843324 - Add up/down arrow navigation in call stack

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

[Nicolas Chevobbe [:nchevobbe]]

Call stack should act like a list box (up and down arrows navigate through frames)

Comment 1

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Callstack with active frame and selected dead frames

Comment 2

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Callstack frames group

Comment 3

[Nicolas Chevobbe [:nchevobbe]]

Hello Anna, while working on this issue, I came across a couple things that we do and that I'm not sure how to handle properly.

Selected vs Active frame

In the callstack, we can have "dead" frames (see the outlined item in Comment 1 screenshot): 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, but it doesn't change the selected frame (in the screenshot, it's still the frame for update on l.22). So this means that we need to differentiate Debugger's active frame from listbox selected item. 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?
Also, since those frames can't be "active", should we have some kind of label on them to indicate they're different?

Grouped frames

For some popular framework, when we have multiple consecutive frames from the same file, we group them behind a single item that can be expanded if need be (in the screenshot from Comment 2, you can see that we grouped 18 frames under a "React" group). Looking at https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-grouped/ , it looks like we can have group in listbox that I could mark with the proper role, and have all the options as children of the group. But, I couldn't find examples of groups being a button/toggle like we're currently doing in the Debugger. Can I have the "React" item being a button that will collapse the group?

Comment 4

[Anna Yeddi [:ayeddi]]

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 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 where nodes can be expanded/collapsed? In this case, there is a Treeview component that devtools has implemented or a Bookmarks sidebar uses its other version too.

[Editing to add this paragraph:] Another way could be to use the accordion pattern 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

Comment 5

[Hubert Boma Manilla (:bomsy)]

Attachment: Bug 1843324 - [devtools] Fix the accessibility for the callstack r=#devtools-reviewers

Comment 6

[Hubert Boma Manilla (:bomsy)]

Hi Anna,
I've added a patch, making the callstack accessible based on some of the suggestions from the discussions above. We would like some thoughts and review on the direction we are going.

Some highlights of this fix

• This switches from "role=list" and "role=listitem" to use UL and LI semantic elements
• Add up/down arrows for navigation through the list, while TABS for moving in and out of the list
• Add support for the HOME and END keys to jump to the first and last elements
• Using different inactive colors for dead frames
• Using aria-activedescendant to manage the active element for the list

Thanks

Comment 7

[Anna Yeddi [:ayeddi]]

(In reply to Hubert Boma Manilla (:bomsy) from comment #6)

Hi Anna,
I've added a patch, making the callstack accessible based on some of the suggestions from the discussions above. We would like some thoughts and review on the direction we are going.

Some highlights of this fix

• This switches from "role=list" and "role=listitem" to use UL and LI semantic elements
• Add up/down arrows for navigation through the list, while TABS for moving in and out of the list
• Add support for the HOME and END keys to jump to the first and last elements
• Using different inactive colors for dead frames
• Using aria-activedescendant to manage the active element for the list

Thanks

Thank you for working on the patch, Hubert!
Let me redirect the NI to Nathan who is leading the DevTools remediation review work and would be reviewing the D227353. ;)

Comment 8

[Nathan LaPré]

Tested it out and left comments on the patch - thanks.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/839aff51a912
[devtools] Fix the accessibility for the callstack r=devtools-reviewers,accessibility-frontend-reviewers,nchevobbe,nlapre

Comment 10

[amarc]

https://hg.mozilla.org/mozilla-central/rev/839aff51a912