Focus states need to be more prominent

[LukasHirt]

Description

Focus styles of all buttons, checkboxes, links does only slightly differ from the normal state - often times it is not obvious which piece of interface has focus

[marcus-herrmann]

Problem (abstract)

It is hard to differentiate the normal state from the focus state. The color contrasts of the border colors of the normal and focus-state don't differ enough.

Solution (abstract)

• If you're relying on color to signify a change in state, the color contrast ratio between the default color and the focus color needs to be at least 3:1*.
• Make sure that any outlines are thick enough to actually see. There aren't any official guidelines on this, but at least use something larger than 1px. There is a WCAG success criteria though that deals with: "Not letting color conveying meaning alone" (1.4.1). So the best practice would be a color matching the needed color and a, for example, thicker outline

* By WCAG Success Criteria 1.4.11 (here's the official explainer document)

Solution in phoenix

Like with most color related issues this isn't a development/code issue alone, it has to be coordinated with a visual design department possibly (and also theming must be taken into consideration). Nevertheless my suggestion for a focus style adhering to the points above would be (simplified code):

.oc-button:focus {
  border-color: #002966;
  box-shadow: inset 0px 0px 0px 1px #002966;
}

[marcus-herrmann]

@PVince81 @LukasHirt

As agreed upon at the sprint planning meeting last monday, here's my take/proposal on much more prominent focus styles, and then show it to @wuenschedesign and the team to gather feedback. I tried to stay inside the established color palette, while still sticking to the contrast ratios quoted above.

Take note:

• Some interactive elements aren't tab stops, especially in the file list. This will be subject to seperate tickets, or in the case of the file list part of the rebuild based on @wuenschedesign's designs
• Usually focus styles show up when you are clicking on an interface element because it will get focus after the click. In the implementation of the focus styles these focus styles will be only visible after keyboard interaction (with the exception of text-inputs)

See below several demo images and a short video of how I would subtly animate the focus.

Here is the short video

[wuenschedesign]

The following drafts show the normal, hover, active, focus and disabled state of input fields and buttons.

Input Fields

Normal Vision	Color Blindness	Low Vision

Buttons

Normal Vision	Color Blindness	Low Vision

[wuenschedesign]

List View with marked Focus States of various elements in the UI:

[wuenschedesign]

@PVince81 @DeepDiver1975 @LukasHirt : I need some feedback, how a focus state must be implemented, e. g. does an additional border change the dimension of an element/button and thus makes a UI „jump“?

[marcus-herrmann]

@wuenschedesign In my "prototyping" for the screenshots above I used CSS properties outline and box-shadow to prevent jumping. There is no hard rule how these styles must be implemented (only regarding visual styling). I prototyped not all possible interactive elements for the demo, only the ones pictured above. But I reckon jumping can be prevented with these measures in general.

[wuenschedesign]

How does a box shadow work with icons (free form as an outline)? Is the shadow applied to the trimbox of the icon or the free form? Is this trimbox always equal to the touch target of an UI item?

[marcus-herrmann]

@wuenschedesign I'm not familiar with the term trimbox, but I guess that is the answer. Like in my demos above, I used box-shadow not for a realistic drop shadow but for a rectangular border that is not part of the CSS box model, therefore preventing a jump (these jumps are at the amount of the "width" of the border, but even noticable when its 1px. Thus: "outline" with box shadow, or where possible, with CSS's outline)

[wuenschedesign]

A preliminary draft to show the status of controls, checkboxes, toggleswitches. Probably there’s no need for a hover or disabled state In certain cases (Making an option invisible instead of turning it to disabled status).

[marcus-herrmann]

@wuenschedesign In my opinion on some items like the favorite star the visual difference between normal and focussed is way too subtle. In some regards it is as un-prominent as the current state in Phoenix.

One info: It is technically possible to restrict the focus styles to keyboard/non-pointer usage alone (:focus-visible in CSS), therefore a user with a pointing device (touch, mouse) won't ever get a focus style, even when they set the control focussed after click (that unwanted effect is the main reason that focus styles get removed in the first place).

So my recommendation is: You can/should be way more bold and obvious with the focus styles (see my demos).