Improve DevTools focus rings

[violasong]

DevTools focus rings that need UX help:

• Tabbing through changeable attributes that already use blue50 to color the entire row, e.g. in Inspector - needs a lighter-colored border, and bolder, maybe 2px to be visible enough.
• Tabbing through changeable text that doesn't use a dark background color, e.g. in Rules.
• Any borderless buttons and other minimalist controls that still use the dotted-line style, which I'm trying to get rid of - these should either use the 'main tabs' or 'margin-less' style focus rings.

DevTools focus rings (UX solved, some implementation needed):

• Simple margin-less fields at the edge of browser screen or toolbar, such as the Console filter field, use a simple 1px blue border.
• Main tabs use hover style as focus style. I’d like to extend this to all of the toolbar buttons in each panel
• Large areas that can be tabbed to and scrolled, such as DOM, should have a "not-focused, selected row" styling, e.g. black-on-gray instead of white-on-blue. (This will be in effect soon for the a11y panel.)
• We would want to use the regular DSG styling for any regular-sized input fields like the checkboxes in Settings

Design System

• This needs to be better documented with images and CSS for the design system.

Examples of Firefox focus rings

It's pretty messy right now but useful for inspiration

[fvsch]

Main tabs use hover style as focus style. I’d like to extend this to all of the toolbar buttons in each panel.

This can be useful, but is not enough for an accessible focus style, because the hover style is too subtle. For keyboard focus, it’s best to also add a strongly contrasted outline (which can be implemented as a CSS outline, border or box-shadow).

A possibly useful trick is to have all buttons use a 1px transparent border:

.some-devtool-button {
  border: solid 1px transparent;
  border-radius: 3px;
  padding: 2px 4px;
}

.some-devtool-button:-moz-focusring {
  border-color: blue;
}

[jasonLaster]

In the debugger and i believe the toolbox, we only show the focus ring on key down. We do not show it on mouse down. I think this is a nice pattern that other tools could benefit from.

[aburone]

Hi. Which one would be the good focus ring?

[fvsch]

The Photon design system defines focus styles for buttons as:

box-shadow: 0 0 0 1px #0a84ff inset, 0 0 0 1px #0a84ff, 0 0 0 4px rgba(10, 132, 255, 0.3)

We could use this style, but Photon elements are often 50% bigger than DevTools elements. So maybe we need to adapt it.

Personally, I would love it if each interactive element could have a 1px border (transparent by default, if the design doesn't use a border). This would enable us to do:

1. Focus styles with a strongly contrasted blue border, plus a lighter 1px or 2px blue box-shadow.
2. High contrast theme where all borders are visible and contrasted.

That would be cool, but I'm not sure a high contrast theme is on the books. So implementing with an inset box-shadow (1px) and an "outset" partial opacity box-shadow (1px or 2px) could be okay.

[aburone]

OK. Sooo. Do I start hacking around and put a PoC here? I've read the proton style guide. Is there one for the devtools (specially the dark theme)

Shall I create a bug for every instance of inputs with the wrong focus (that would be madness IMHO)

Also I realize that ie RDM styles are totally isolated from other tools. But in the inspector the changes I tried with other bug affected the settings.... Is there any documentation about this behavior?

[fvsch]

Also I realize that ie RDM styles are totally isolated from other tools. But in the inspector the changes I tried with other bug affected the settings.... Is there any documentation about this behavior?

The code is the documentation. ;)

Some stylesheets are generic and loaded in most all contexts, including:

• devtools/client/themes/variables.css
• devtools/client/themes/common.css

Some stylesheets are loaded only by a given tool, they can be in the devtools/client/themes/ folder or in a tool's own folder (devtools/client/foo).

[fvsch]

Do I start hacking around and put a PoC here? Shall I create a bug for every instance of inputs with the wrong focus (that would be madness IMHO)

The current situation is that there are a lot of different ways that focus styles are applied, with many different styles; sometimes no focus styles are applied at all for some interactive elements (which is an accessibility bug); and often those focus styles are applied on clicks, which we would like to prevent (see Dealing with sticky focus styles for a general explanation, and :-moz-focusring for a way we could implement that in DevTools).

We still need to define the exact behavior and look we want to achieve, but a proof-of-concept implementation would help seeing an improved behavior and look in action, so that we can create a clear guideline.

So the next step could be:

1. Implement a proof of concept in a limited part of DevTools.
2. With feedback from UX and accessibility people (Victoria, Matt and yzen), create a design document that specifies what kind of result we want to achieve (how it should behave and look).
3. Then we can create bugs for implementing that design; probably one bug per tool or per tool panel.

Steps 2 and 3 also depend on project management decisions. We should not go off and define a large change and open 30 bugs or more without input and some sort of sign-off. ^^

@violasong Does this plan sound good to you?

@aburone I think you can start working on step 1 if you're interested; I would suggest working on the Network monitor for the proof of concept, and focus on 3 areas: the top toolbar, the "no requests" view, and the request table (excluding the request details that appear on the right when selecting a row). This gives us plenty of different use cases: buttons that touch their container's sides, buttons that are offset from the toolbar's sides, text input that takes the full toolbar height, select buttons, table headers, table rows, etc. For this POC I would recommend creating a new stylesheet to load in the netmonitor iframe, and trying to override existing styles if needed.

[aburone]

Perfect. When I have something to show, shall I upload a patch in a bug report? Or is there another preferred way?

[fvsch]

I think you can create a bug, e.g. "Explore new focus ring styles in Netmonitor", and reference this issue. Then you can upload a patch to Phabricator (with r=fvsch). I'll note in the bug that we won't merge it.

[aburone]

Florens I created a html file with the basic idea and the different triggers. I used different focus color for dark and light themes. Everything is defined in variables for easier tinkering.

Let me know how far away of the mark I've got so I can create a better PoC in the actual devtools. https://bugzilla.mozilla.org/show_bug.cgi?id=1502098

[fvsch]

Nice, I've commented on bugzilla. Let's try to make progress there for now.

[violasong]

Hi @aburone and @fvsch, I'm so happy to see you working on this bug and I would really like to help more with this. I'm currently needing to focus on some tight deadlines coming up so I can't think about this much right now. I'm happy to go with Florens' plan and jump back in with feedback sometime next week when I'm able to. Thanks so much!

[fvsch]

We have a design proposal ready for review at https://bugzilla.mozilla.org/show_bug.cgi?id=1502098#c16

[fvsch]

Discussed at All Hands with @violasong and :yzen.

Main decisions:

1. The proposal at https://fx-devtools-focusring.netlify.com/ is mostly validated; we'll probably drop the inset shadow for edge-to-edge elements.
2. We do need an implementation that avoids adding focus rings on buttons after mouse clicks. Pending an implementation of :focus-visible in Gecko, we may need to experiment with using a polyfill. The Accessibility tool already uses Photon focus styles, and some JS hacks to prevent focus styles after clicks.

One way to go forward is to prototype implementing the new styles and the :focus-visible polyfill in the Accessibility tool. I'll change the Bugzilla bug with this goal.