[RFC] Adjust how Circuit UI deals with focus styles

[felixjung]

Proposal

This proposal suggests to

• Apply focus styles globally by default to improve general accessibility out of the box.
• Use consistent focus styles to help with identifying the focus state.
• Adopt the new :focus-visible pseudo-class, with fallback/polyfill, to make focus styles only appear when a user actually uses the keyboard to navigate.
• Keep a style helper around for manually applying focus styles.

Context

Focus styles are an important accessibility feature. Users navigating a web page with a keyboard rely on focus styles to indicate which interactive page element is currently in focus and can be activated. Browsers ship with default focus styles for various elements.

Circuit UI, as far as I can tell, has three ways of dealing with focus styles.

• Form components like Input, Select, or Checkbox come with form-specific focus styles -- a relatively thin but high contrast border.

• The Button and Anchor components ship with a lighter and wider blue border focus style.

• For custom components in applications depending on Circuit UI, developers should use the ~undocumented~ (docs have been added) focusOutline style mixin. This, for example, could be used when turning an image into a link without using the above-mentioned Anchor component.

Shortcomings

The current situation has the following shortcomings

• Having different focus styles on form elements and anchors or buttons makes it slightly more difficult to tell that an element is in focus. Consistent focus styles would help with that.
• What we aim for is to have great accessibility out of the box. However, by relying on focus styles at the component level, we leave room for inconsistent focus styles. If developers do not use Circuit UI components for certain elements and do not apply the focusOutline style helper, the browser will fall back to its default focus styles. This introduces a third focus style on the web page/app on top of the existing ones documented above. It would be better if focus styles were applied globally on an element basis.
• We rely on the :focus pseudo-class to apply focus styles. This has the disadvantage of triggering focus styles in some cases where users are using a mouse. Browsers have started adopting a new pseudo-class, :focus-visible, from the CSS4 working draft to deal with this scenario. When using this pseudo-class, the browser determines whether the user needs to see focus styles or not. There are ways to use it in a backward compatible way. This article on CSS Tricks explains the pseudo-class in more detail.

Potential downsides

• Please get in here, I don't know any.

[larimaza]

I don't see any downsides to this as well 🤷‍♀️ Let's do it!

[long-lazuli]

I just wanted to add to this discussion that the CSS rule @support was supported by browsers almost always before the :focus-visible !

So we might do something like this (pseudo-code):

.component:focus { outline: ${focusStyle}; }
@support(:focus-visible) {
  .component:focus { outline: initial; }
  .component:focus-visible { outline: ${focusStyle}; }
}

( Opera Mini is an exception. so :focus would be used there. )

[connor-baer]

• Having different focus styles on form elements and anchors or buttons makes it slightly more difficult to tell that an element is in focus. Consistent focus styles would help with that.

Personally, I don't see the two different focus styles as an issue. Both styles make it obvious that the element is in focus and having two styles to choose from makes it possible to adapt to an element's design.

• What we aim for is to have great accessibility out of the box. However, by relying on focus styles at the component level, we leave room for inconsistent focus styles. If developers do not use Circuit UI components for certain elements and do not apply the focusOutline style helper, the browser will fall back to its default focus styles. This introduces a third focus style on the web page/app on top of the existing ones documented above. It would be better if focus styles were applied globally on an element basis.

It's true that we want to provide the most accessible experience possible. However, some things can't be handled by the component library and need to be taken care of by developers. I believe this is one of those cases.

Applying focus styles globally is technically complex. You have to account for border-radii, composite elements, et cetera. The effort and amount of code that's necessary to make a global solution work for all use cases is not worth it.

I believe proper focus styles and focus management is web development/accessibility 101. I expect every web developer to be familiar with it, and if they're not, I'd be happy to teach them.

• We rely on the :focus pseudo-class to apply focus styles. This has the disadvantage of triggering focus styles in some cases where users are using a mouse. Browsers have started adopting a new pseudo-class, :focus-visible, from the CSS4 working draft to deal with this scenario. When using this pseudo-class, the browser determines whether the user needs to see focus styles or not. There are ways to use it in a backward compatible way. This article on CSS Tricks explains the pseudo-class in more detail.

Since this issue was created, we've switched to :focus-visible with a fallback for browsers that don't support it yet.

Considering my points above, I'm in favor of closing this issue.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Add a comment explaining why the issue is still relevant to prevent it from being closed.