1870062 - Breakpoint isn't a button while it can be clicked

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

[Alexandre Poirot [:ochameau]]

Bug 1834729 expanded the coverage of browser_dbg-editor-select.js, but trigerred an a11y warning on Breakpoint Element:
https://searchfox.org/mozilla-central/rev/4d6a5b97428760d15bfcad13f8fc81439370a7ec/devtools/client/debugger/src/components/SecondaryPanes/Breakpoints/Breakpoint.js#134-187
which is using a div while it can be clicked.

Comment 1

[Anna Yeddi [:ayeddi]]

Hi Alexandre, it seems that the breakpoint element could be made accessible with role="button" added.

It may not need to be keyboard focusable with tab key, depending on the keyboard navigation on the page (if it's included in the focus order with arrow keys as the tabpanels do, for instance, then you may need to AccessibilityUtils.setEnv({focusabeRule: false}) right before the click on it and then AccessibilityUtils.resetEnv() after the click in the test file), but adding a role would at least allow this element to be usable with voice control software and to be discoverable in the list of controls of a screen reader.

LMK if I can help.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S3. However, the accessibility severity is higher, .
:bomsy, could you consider increasing the severity?

For more information, please visit BugBot documentation.

Comment 3

[Hubert Boma Manilla (:bomsy)]

We don't usually align a11y severity with the devtools ui bug severity.

Comment 4

[Nicolas Chevobbe [:nchevobbe]]

(In reply to Anna Yeddi [:ayeddi] from comment #1)

Hi Alexandre, it seems that the breakpoint element could be made accessible with role="button" added.

It may not need to be keyboard focusable with tab key, depending on the keyboard navigation on the page (if it's included in the focus order with arrow keys as the tabpanels do, for instance, then you may need to AccessibilityUtils.setEnv({focusabeRule: false}) right before the click on it and then AccessibilityUtils.resetEnv() after the click in the test file), but adding a role would at least allow this element to be usable with voice control software and to be discoverable in the list of controls of a screen reader.

LMK if I can help.

Hello Anna, we were discussing how to make adding/removing a breakpoint keyboard accessible with the team.

Breakpoint can be set/removed on a line by navigating to said line in the document (or use Ctrl+G to go to specific line), and then hit Ctrl+B (Cmd+B on Mac) to toggle the breakpoint. And once you set a breakpoint, you can disable it/remove it from the breakpoints panel.
Is this enough to consider breakpoints management keyboard accessible, or not?
Those shortcuts are displayed in our shortcut panel, but they're pretty hidden as you need to hit Ctrl+/ (Cmd+/ on Mac)

Having the gutter element as buttons doesn't feel super straightforward, especially if you need to add a breakpoint on a line at the very bottom.
I remember reading about how making something accessible is sometimes not about making the UI elements accessible, but simply having a way to perform the operation, even if it's through some other way. But maybe in this case this doesn't apply?

Comment 5

[Anna Yeddi [:ayeddi]]

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #4)

(In reply to Anna Yeddi [:ayeddi] from comment #1)

Hi Alexandre, it seems that the breakpoint element could be made accessible with role="button" added.

It may not need to be keyboard focusable with tab key, depending on the keyboard navigation on the page (if it's included in the focus order with arrow keys as the tabpanels do, for instance, then you may need to AccessibilityUtils.setEnv({focusabeRule: false}) right before the click on it and then AccessibilityUtils.resetEnv() after the click in the test file), but adding a role would at least allow this element to be usable with voice control software and to be discoverable in the list of controls of a screen reader.

LMK if I can help.

Hello Anna, we were discussing how to make adding/removing a breakpoint keyboard accessible with the team.

Breakpoint can be set/removed on a line by navigating to said line in the document (or use Ctrl+G to go to specific line), and then hit Ctrl+B (Cmd+B on Mac) to toggle the breakpoint. And once you set a breakpoint, you can disable it/remove it from the breakpoints panel.
Is this enough to consider breakpoints management keyboard accessible, or not?
Those shortcuts are displayed in our shortcut panel, but they're pretty hidden as you need to hit Ctrl+/ (Cmd+/ on Mac)

Having the gutter element as buttons doesn't feel super straightforward, especially if you need to add a breakpoint on a line at the very bottom.
I remember reading about how making something accessible is sometimes not about making the UI elements accessible, but simply having a way to perform the operation, even if it's through some other way. But maybe in this case this doesn't apply?

Thank you for the context, Nicolas! Thank you for continuing working on the dev tools a11y.

Maybe we could make the added breakpoints as role=button and use a list navigation (aka "inside component navigation or arrow navigation) between them? Then, when someone used a shortcut to set up a breakpoint, they could still find and activate it to remove it from the code.

CCing Jamie in case there are other options to improve the adding/removing breakpoints for keyboard users.

Comment 6

[Nicolas Chevobbe [:nchevobbe]]

(In reply to Anna Yeddi [:ayeddi] from comment #5)

Maybe we could make the added breakpoints as role=button and use a list navigation (aka "inside component navigation or arrow navigation) between them? Then, when someone used a shortcut to set up a breakpoint, they could still find and activate it to remove it from the code.

Thanks a lot for the reply Anna, I'll have a look into that.

Comment 7

[Nicolas Chevobbe [:nchevobbe]]

Let's only do this for CodeMirror 6, as cm5 might require a very different solution

Comment 8

[Hubert Boma Manilla (:bomsy)]

Attachment: Bug 1870062 - [devtools] Make the breakpoint items in the breakpoints panel accessible r=#devtools-reviewers

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a157c48ede88
[devtools] Make the breakpoint items in the breakpoints panel accessible r=devtools-reviewers,nchevobbe

Comment 10

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/a157c48ede88