Universal Focus State

[mceledonia]

Designing a focus state pattern which works across all components. The focus state visual design should be independent of the component's other states such as hover or active.

Focus State PF4.png.zip

[LHinson]

Just realized there is issue #786 @jgiardino states:

One of the WCAG items we need to meet is to clearly indicate focus (WCAG 2.4.7).

Our original approach has been to rely on the browser defaults for indicating focus. But currently there are a couple of issues with this:

• Our current styles override the default styles provided by Firefox for some elements, like buttons
• Some components might not be able to rely on browser default styles. For example, in a Switch component that's based on a native html checkbox, we're hiding the checkbox which is the element that receives focus, which means the focus is not visible to the user.

P.S. WCAG link above includes links to additional information about how to meet this criteria.

[mceledonia]

Universal focus state visual design

Focus State PF4.png.zip

[guillaumevincent]

in the design I shared, border is #007BBA and the background is also #007BBA at 15% transparency

from @mceledonia on slack

[andybraren]

Just dropping a note here that whenever this gets implemented it should be tested with the Tabs component. Discussion about this starts here.

[mceledonia]

Giving this a bump @rachael-phillips @mcoker design work here should be done, might need to have some discussion around how this behaves with certain components such as tabs and input groups, but overall I think we are set to implement.

[mceledonia]

Want to note here the last discussion that took place on this topic:

We would like to shift directions here, going with browser default focus states when applicable, and our custom focus state design only when the browser default state does not work. We reached this conclusion after a better understanding that keyboard users are far more accustomed to and expect browser default focus states. As this is an accessibility focused feature, we want to accommodate that use case as best as we can by providing an expected experience.

[mceledonia]

bump @rachael-phillips @jgiardino @mcarrano @mcoker @LHinson

[jgiardino]

Thanks for recapping that here, @mceledonia!

If this issue is only to focus on components that require custom focus indication, then can we bump this up in priority to address components that need this?

[LHinson]

Do we understand how many components are impacted and which ones those are @jgiardino ?

[mceledonia]

@LHinson I think that will take some coordinated efforts with dev + design to test which components work with browser default states and which do not. I'd be happy to help with this.

[garrett]

I've been working on something related to this issue within the scope of Cockpit.

---

We needed to replace the on/off switch component in Cockpit, for several different reasons (including usability and accessibility). I opted for making something that resembles PF4, but with PF3 colors, so it wouldn't clash.

As the PF4 widget doesn't have focus, when implementing ours, I figured out a way to get native-looking focus states into our custom widget and how to have them show up on keyboard navigation without displaying on a mouse click.

Our HTML is similar to this demo, but a little different. It's in React and swaps things out a bit, whereas this demo is pure HTML+CSS. The LESS is basically copy/pasted from our codebase.

DEMO at https://codepen.io/garrett/pen/MRZYaV — be sure to check it in multiple browsers. (Basically Firefox and something that's not Firefox.) To see a focus ring, click on a heading and hit tab.

Outlines are created with absolute positioning on a ::before pseudo element, so they are outside of the flow of the document.

By default, the outlines use a Chrome-style blue outline, but switch to a dotted outline for Firefox, using @-moz-document url-prefix() {}.

To get around styling a click versus tab, I figured out that we could use transition-delay in conjunction with a hover to set the borders to transparent. As there is not state to transition from tab, the rings instantly appear. When clicking with a mouse, hovering is implied, so they transition from transparent to a visible color in 300ms — but 10 minutes later. (The time is arbitrary, as long as it's far enough in the future.) It only affects the currently hovered element during the activation, so tabbing around still works as expected. The only gotcha is that Edge still shows the rings on a click (at least in my testing VM, which could be doing something odd) — but Edge is going away soon anyway. It works perfectly everywhere else.

(In the future, we could rely on :focus-visible, but no browsers support it yet. There's a polyfill that kind of implemented it, but I wanted to figure out a solution in pure CSS.)

---

Perhaps some of this might be useful for PF4's focus state? We could use native focus indicators where possible and emulate them with above techniques for custom widgets.

[jgiardino]

@garrett Thanks for sharing your example! It's a great POC on the things that should be considered regarding focus styles.

I chatted with @mcoker and @mceledonia today about how to address this in PF4, and ultimately we're leaning toward a minimal approach to handling focus styles, at least initially. This is a summary of what we discussed.

• We are not implementing universal focus styles, and are taking the approach that @mceledonia mentioned above, and therefore can close this issue and open new issues for specific components that do require custom styles
  • Currently, this is only needed for the Switch: Focus state for switch #1824
  • But in the future, we should revisit the Typeahead variant of the Select once we finalize keyboard interaction: Select - TypeAhead variants - keyboard and screen reader accessibility patternfly-react#1842
• We discussed what the visual style should be, and if we should emulate browser styles or not. The general assumption is that users become familiar with the native styles for focus state in the browser they use the most, which is a compelling reason to do something that is consistent with the browser the user is using. That might be the approach we end up taking in a future release, but for now, to keep the initial implementation simple, we will use one style for all browsers. And we will choose a style that clearly indicates focus, matches the default theme, and doesn't necessarily try to emulate any one browser.
• Everyone agreed that showing focus styles only on keyboard interaction and not with mouse interaction is a preferable user experience. But we also didn't discuss if this is something we should try to do where the browser applies focus styles. I'm inclined to let browsers decide how to handle this for native interactive elements. For the switch, I'll defer to others on what should happen here.
• There are styles that only display on focus (e.g. the focus ring), but additionally there are styles that display on hover. Moving forward, styles that display on hover should also display on focus, in addition to the focus ring.

@mceledonia @mcoker Please add anything I missed, or correct me if I captured something incorrectly. :-)

[mceledonia]

Just wanted to leave this spec here with our new blue color change:

[deleted] see below

[mceledonia]

Commenting to update: new styling for universal focus state here #1824