Open Bug 1502098 Opened 6 years ago Updated 2 years ago

Prototype new focus styles in DevTools in the Accessibility tool

Categories

(DevTools :: General, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: aburone, Unassigned)

References

Details

Attachments

(2 files, 4 obsolete files)

Attached file focus ring and input colors (obsolete) —
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

This is a PoC
For context, this is an exploration of this UX issue:
https://github.com/devtools-html/ux/issues/7

So I've looked at the current codebase a bit, and we have a few variables create to handle focus styles, with several styles:

1. Some elements have a dotted 1px outline, with the outline color explicitly set to white or black (depending on the theme): `--theme-focus-outline: 1px dotted var(--theme-focus-outline-color);`

2. Some elements, especially text inputs in the Inspector toolbars (the `.devtools-searchinput` class in common.css), have a 1px border that goes blue and a 1px light blue shadow.

3. We have full-height, borderless text inputs (in Console and Network toolbars) that get a 1px blue border when focused.

Then we have all the other configurations shown in Victoria's composite screenshot.

What these show is that, unlike the bigger Photon UI, whose guidelines apply to things like the 40px-high Firefox toolbars and page content like about:preferences, in DevTools we have more compact situations like the toolbars (24px or 28px high), with some elements that may go edge-to-edge by design, or which can have a 1px blank space around only.

So I think we should:
- adapt Photon guidelines for this more compact setting
- and try to handle edge-to-edge interactive elements elegantly

So the first design guideline I would use is:

Rule 1. All interactive elements must have a 1px border. That border can be visible by default or, more often, it can be transparent.

The idea is that we can make this border visible or more prominent when focused, and for other needs if necessary (some hover or "pressed" styles, maybe). Borders also have two advantages over outlines:
1. They follow rounded corners (border-radius)
2. They could be used for a "high contrast" mode, which usually makes most borders much stronger to help distinguish elements

Then for focus styles only we should try to add a light blue shadow, but I think we need a smaller one, and we may need a few different styles to handle different situations:

- a 1px outer shadow (same as `.devtools-searchinput` currently), no inner shadow
- or a 2px outer shadow (similar but larger; may not render well in toolbars), no inner shadow
- or a 2px inner shadow for edge-to-edge elements
Re. your HTML test, can you try to update it with:

- no combined inner and outer shadow (just one or the other)
- 2px outer shadow, 1px outer shadow, and 2px inner shadow variants
- <button type="button"> for buttons (doesn't submit the form, which helps testing)
- and quite importantly, only using :-moz-focusring and no :focus

I think for now we can focus on the light theme only, to make things simpler.
Assignee: nobody → aburone
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Component: Untriaged → General
Product: Firefox → DevTools
Version: 65 Branch → unspecified
Attached file focus ring 2 (obsolete) —
Three border variants (color, transparent, greys)
Shadows: 1px, 2px, 2px light, inset 2px light
Dark theme takes no extra time :)

There are styles that make no sense because of the combination, but I've let them to avoid copy/paste errors.
Attachment #9020067 - Attachment is obsolete: true
Attached file checkbox & radio (obsolete) —
Added checkbox and radio to first lines
Attached file checkbox & radio (obsolete) —
Added checkbox and radio (scaled down) on first line.
Attachment #9020276 - Attachment is obsolete: true
Thanks for the visual explorations Ariel. I'd like to take some time this week to create a HTML mock-up with situations closer to what we have in DevTools (especially restricted space situations like toolbars) and select a few focus styles that seem to work.
(In reply to Florens Verschelde [:fvsch] from comment #6)
> Thanks for the visual explorations Ariel. I'd like to take some time this
> week to create a HTML mock-up with situations closer to what we have in
> DevTools (especially restricted space situations like toolbars) and select a
> few focus styles that seem to work.


I can do it. Just tell me which combination or combinations would be the best and I can apply them.
I could then upload several patches or screenshots (whichever is more convenient to you)
Just a couple of comments regarding accessibility of the styles:

* having no additional shadow is less accessible because focused state is then only represented by colour. When there's an additional shadow, it is more clear that something is focused for persons with colour blindness or low vision.

* dark theme focus styling for check boxes and radio buttons has insufficient contrast. I believe this is because unlike buttons and text areas/inputs the background remains white vs dark background outside the control.

* light styling used together with the dark theme has low contrast and might be hard to see for low vision users.

* transparent border with no shadow is not accessible
Attached file focusring.html
Attachment #9020275 - Attachment is obsolete: true
Attachment #9020278 - Attachment is obsolete: true
@yzen
> * having no additional shadow is less accessible because focused state is
> then only represented by colour. When there's an additional shadow, it is
> more clear that something is focused for persons with colour blindness or
> low vision.

+100. But it seems like the style guide calls for it :(

> 
> * dark theme focus styling for check boxes and radio buttons has
> insufficient contrast. I believe this is because unlike buttons and text
> areas/inputs the background remains white vs dark background outside the
> control.

Indeed the only style that makes them more visible is having a shadow
I added the checkboxes and radios to all lines so it's easier to compare at a glance.

> 
> * light styling used together with the dark theme has low contrast and might
> be hard to see for low vision users.
> 

I added a style option with dark inset shadow for comparison.

> * transparent border with no shadow is not accessible
Indeed

But nothing of this is my call, so  ¯\_(ツ)_/¯
The moment I get a confirmation of what provisional styles to use, I can do a PoC in the devtools themselves.

IMHO, this should not be only a focusring thing, but making all input styles accessible and consistent across tools.
*ducks and run*
I started a HTML-CSS design document here:
https://fx-devtools-focusring.netlify.com/ (deployed from https://github.com/fvsch/fx-devtools-focusring)

This design's rationale is to show a strong outline on buttons only when using keyboard navigation, and not after clicks. This is why we use a :focus-visible polyfill. I thought we could use :-moz-focusring, but in my tests it applied after clicks on buttons. So it seems we are blocked on :focus-visible implementation in Firefox (bug 1445482).

The style I'd like to keep is a 1px blue border with a 2px lighter blue shadow.
For text inputs and buttons that touch the toolbar's edges, the idea would be to use an inset shadow instead of a drop shadow.

The shadow is more visible in the light theme than in the dark theme IMO. I tried using stronger opacity (40-50% instead of 30%) or lighter colors, but it looks awkward. So for now I've kept the same, hardly visible shadow.

Two things needed to go forward:

1. If you think a different style would work best, please provide feedback.
2. I'd like to add more examples to this document, especially edge-to-edge buttons and tabs (like those in the main top bar).
Ariel, do you think you could work on https://github.com/fvsch/fx-devtools-focusring and make a PR if you have a GitHub account, and try to implement a edge-to-edge button (like the "Pick an element" button) and a tab style, both with border+inner shadow? No JS needed, it doesn't have to replicate the actual behavior of devtools tab.
(In reply to Ariel Burone from comment #10)
> @yzen
> > * having no additional shadow is less accessible because focused state is
> > then only represented by colour. When there's an additional shadow, it is
> > more clear that something is focused for persons with colour blindness or
> > low vision.
> 
> +100. But it seems like the style guide calls for it :(

That's true, though this is probably the right place to discuss these issues.

> > * transparent border with no shadow is not accessible
> Indeed
> 
> But nothing of this is my call, so  ¯\_(ツ)_/¯
> The moment I get a confirmation of what provisional styles to use, I can do
> a PoC in the devtools themselves.
> 
> IMHO, this should not be only a focusring thing, but making all input styles
> accessible and consistent across tools.
> *ducks and run*

Totally agree
(In reply to Florens Verschelde [:fvsch] from comment #11)
> I started a HTML-CSS design document here:
> https://fx-devtools-focusring.netlify.com/ (deployed from
> https://github.com/fvsch/fx-devtools-focusring)
> 
> This design's rationale is to show a strong outline on buttons only when
> using keyboard navigation, and not after clicks. This is why we use a
> :focus-visible polyfill. I thought we could use :-moz-focusring, but in my
> tests it applied after clicks on buttons. So it seems we are blocked on
> :focus-visible implementation in Firefox (bug 1445482).
> 
> The style I'd like to keep is a 1px blue border with a 2px lighter blue
> shadow.

I agree that the 2px lighter blue styling looks like it has good balance. 

> For text inputs and buttons that touch the toolbar's edges, the idea would
> be to use an inset shadow instead of a drop shadow.
> 
> The shadow is more visible in the light theme than in the dark theme IMO. I
> tried using stronger opacity (40-50% instead of 30%) or lighter colors, but
> it looks awkward. So for now I've kept the same, hardly visible shadow.

Yeah it seems like opacity solution would not work since it's blending with the darker background. It seems like we need something inverse to that.. Perhaps Victoria has some opinions too..

> 
> Two things needed to go forward:
> 
> 1. If you think a different style would work best, please provide feedback.
> 2. I'd like to add more examples to this document, especially edge-to-edge
> buttons and tabs (like those in the main top bar).

It'd be also great to consider icon links/buttons that have no borders (for example debugger tab bottom right cornder). As well as focus/hover/active styling for links.
Attached image Check box vs button
I also noticed that outline border styling do not much for buttons/text areas and radios/checkboxes. Sorry if this is something expected
Final comment, check boxes and radios (and sometimes buttons) have a state when they are selected/checked/pressed, it often conflicts with focused styling, especially in terms of colour contrast - something to have in mind.
Severity: normal → enhancement
Priority: -- → P3
Here is an updated focus ring design proposal:
https://fx-devtools-focusring.netlify.com/

The design principle looks like:

1. Make sure every focusable elment has a 1px border, even a transparent one, which can turn blue when focused
2. Complement this border with an outer box-shadow (2px)
3. For elements that touch the edges of their container, use an inset shadow instead

IMO this looks good in the light theme, and might be a bit less pleasing with the dark theme. But maybe we don't need to refine the dark theme look too much, since it's already less contrasted than the light theme which is our de-facto "most accessible" theme (and used by close to 95% of users last I heard).

I still tried a dark theme variant were we use a 2px solid blue border (1px border + 1px shadow, same color/opacity).

Victoria, what do you think?
Flags: needinfo?(victoria)
See Also: → 1476296
(In reply to Florens Verschelde [:fvsch] from comment #16)
> Here is an updated focus ring design proposal:
> https://fx-devtools-focusring.netlify.com/
> 
> The design principle looks like:
> 
> 1. Make sure every focusable elment has a 1px border, even a transparent
> one, which can turn blue when focused
> 2. Complement this border with an outer box-shadow (2px)
> 3. For elements that touch the edges of their container, use an inset shadow
> instead

Florens, these looks good!

> 
> IMO this looks good in the light theme, and might be a bit less pleasing
> with the dark theme. But maybe we don't need to refine the dark theme look
> too much, since it's already less contrasted than the light theme which is
> our de-facto "most accessible" theme (and used by close to 95% of users last
> I heard).

I would encourage to not think about percentages and quantities when working on accessibility improvements. Designing with accessibility in mind implies designing for the margins. In many cases (in general) low numbers for usage imply some sort of barrier.

The only remaining issue with the dark theme seem to be controls like checkbox/radio.

Final question/comment I have if "Switch theme" button itself is part of the example/proposal. If so, focus state represented with colour only is not accessible (perhaps box shadow missing?).

> 
> I still tried a dark theme variant were we use a 2px solid blue border (1px
> border + 1px shadow, same color/opacity).
> 
> Victoria, what do you think?
I looks like this died...

Just for adding this. I still think that focus for mouse is useful and I'm not the only one.
https://gomakethings.com/just-use-focus-styles-damnit/
Not dead, some things just take time ;)

I'm going to take the lead on this issue, if you don't mind. I'll probably be able to discuss it with Victoria next week, to validate the design. Then for going forward we will _probably_ need a JS implementation or a Gecko implementation of :focus-visible.

> I still think that focus for mouse is useful and I'm not the only one.

Re. the idea of showing focus styles on everything interactive after clicks: I know that [developers who are used to :focus and coding focus styles] often don't mind those, because they can mentally process them; some, like you and Chris, may find it useful. But we're also getting feedback from users that even subtle :focus styles are confusing when they make a button appear "pressed". That's a problem for two types of buttons:

- Action buttons with no "pressed" or "checked" style: we don't want users to see them as two-state buttons.
- Toggle (2-state) buttons, checkboxes and radio inputs, especially after you've just clicked them to get a "unchecked" state.

In DevTools UI, that's a majority of focusable elements.

IMO if we want to "just use :focus for everyone", we would need two bits of supporting information:

1. Data from UX experiments that show how big the [users who misunderstand focus styles] segment might be, and/or if that user segment eventually learns about focus styles and appreciate them.
2. Guidelines for designing a focus style visual language that is distinct from the "active|pressed|checked" visual language.
Assignee: aburone → florens
Summary: Exploring new focus ring styles → Prototype new focus styles in DevTools in the Accessibility tool
From GitHub:

> 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.
Flags: needinfo?(victoria)
Assignee: florens → nobody
Status: ASSIGNED → NEW
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: