wcss: active halo

[blackfalcon]

The scope of this issue is to address, once and for all, the issue related to accessibility and an active halo.

The position of Auro is to use focus-visible, but there have been recent updates that are causing inconsistent issues with the active state and the halo between elements and experiences in different browsers.

For example, open a dialog window in the Auro site. One in Safari and one in Chrome.

In Safari, there is a halo. In Chrome, there is not.

[blackfalcon]

This is another weird issue that came up post the updates to WCSS
https://github.com/AlaskaAirlines/auro-radio/pull/24/files#diff-5e92b45e38fe7e0cc316df5ae98bf30ebb7a8c065e698c91ee0055d9f33c6781R25

[geoffrich]

The differences with Safari has to do with how the Sass is being generated.

It looks like whatever is compiling the Sass is combining the focus-visible declarations in WCSS, presumably because they share a ruleset:

.js-focus-visible :focus:not(.focus-visible), :focus:not(:focus-visible) { /* whatever */ }

They are separate in the _core.scss stylesheet to prevent browsers that do not support :focus-visible from throwing the whole rule out. With how it's currently minified, Safari will not remove focus styles as expected because it does not support focus-visible.

[geoffrich]

The issues like the one with auro-radio are expected. There was an implicit dependency on WCSS removing all focus outlines all the time, so the component never had to worry about removing the default outline. Now that outlines are only removed when focus-visible is loaded (much better for a11y), components need to reset the default focus outline when they declare their own focus styles.

For example, see the update I made to auro-button.

[blackfalcon]

This is no longer an issue that needs to be specifically addressed.