Page MenuHomePhabricator

Consider changing default focus style (e.g. for links) to match WMUI
Open, LowPublic

Description

In Chrome 81, the default focus style has been made much strong to improve accessibility:

Chrome 80Chrome 81

It is now very similar to the WMUI focus styling, which is 2px outline in dark blue instead of black, so we should probably just align it with WMUI.

That said, the new outlines can make text hard to read:


so we may just want to come up with our own solution.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 21 2020, 11:03 PM
Demian added a subscriber: Demian.Feb 22 2020, 3:41 AM

A suitable rounded background gives much better UX. Interactions with icons, the logo and labelElements (ex. in search) need a bit of fine-tuning.

I think the point here is to unify our focus styles, not create a new one. The proposal is to make the outline blue to match our existing focus styles in WMUI:

Demian added a comment.EditedFeb 23 2020, 6:11 PM

I think the point here is to unify our focus styles, not create a new one.

That's food for the thought. Focus styles are usually overlooked in webdesign and this is the case here too. The default outline is often hard to recognize and almost always makes the text less readable and it also lacks design finesse (it's ugly).

That being said, back to the original "focus":
Making it blue (#36c - Accent50) is an obvious step to take imho. If somebody has better idea... then it will be changing the style, as said above.

The question that has weight imo is "How?".

  • outline-style: auto; will effectively turn the #36c color into #a0b1e5.
  • The rest of the outline styles won't round the corners.
  • Buttons use a combination of: border-radius: 2px + box-shadow: 1px inset #36c +border: 1px solid #36c. I wonder why that resource-consuming double solution is used. Let's evaluate these options separately.
  • Using a 2px border changes the layout, that can be compensated with negative margin, but that spoils the positioning of the notification icons, maybe more. Notification icons still use the <a> element... technical debt.
  • Using a 2px box-shadow was the least problematic, I've seen no issues with it. Outset, not inset, see samples, why.
    • box-shadow: 0 0 0 2px #36c;

To address the border being too close to the text (demonstrated with "lol"), a 2px horizontal padding can be added to <a> elements. This can be compensated with a -2px horizontal margin.
The notification icons are unaffected, but it might have inadvertent effects in some hidden places, that need to be checked.

Samples

All taken with border-radius: 2px;

outline auto (Chrome 80)outline solid 2pxborder solid 2pxbox-shahow inset 2pxbox-shahow outset 2px

Note: screenshots taken with Timeless' 15.2px font-size. Vector with 14px looks worse. Sidenote: fix the font-size.

Vector:

Thanks. The box-shadow outset was the one I was experimenting with, and would probably be the best approach here.

alexhollender triaged this task as Low priority.Mar 10 2020, 4:23 PM
alexhollender added a subscriber: alexhollender.

@Volker_E do you have thoughts on this? What is the current thinking around why we don't apply custom styling for blue links, as we do for OOUI elements?

Have updated today to v81 and on macOS it's still the blue from before, relying on outline: -webkit-focus-ring-color auto 5px;
@Demian @alexhollender We needed to provide our own focus styles based on border and box-shadow to apply outline in a visually satisfying clear manner in plethora of our widgets based on combination of elements.
We have left link styles out of the game so far as it, among other reasons, wasn't part of OOUI's responsibility.

An issue when applying Accent50 to the outline is, what is already visible Demian's write-up above, that the color would effectively turn into something darker, more grey, which we clearly would want to prevent.


Not much more exciting.

I think the black accessible outlines were pulled in the Edge port, but clearly the OSX build is still special.

wasn't part of OOUI's responsibility.

Yes, plain links are not OOUI widgets, however the WMUI theme/style-guide applies to more than just OOUI widgets.

I think this would definitely be an improvement for chrome+windows/linux where the black outline is default. It is less clear if we want to change the browser defaults elsewhere (chrome+osx, Firefox, ...).

Jdlrobson moved this task from Needs triage to Technical on the Vector board.May 15 2020, 5:00 PM

Revisiting with some distance. Have prepared a reduced test case:
https://codepen.io/Volker_E/pen/QWyNpwP

I think it's seriously to consider alongside what @Esanders has been requesting here.

We could reduce code to

:focus {
  outline-color: #36c; /* Variable to be used instead of static value in prod code. */
}

With this we wouldn't interfere with our own components focus styles and still provide a consistent look with the custom ones.

Effect as intended, very close to Wikimedia Design Style Guide components focus
Chrome v81+/macOS; Edge v83+/Win 10; Yandex 14.12, Samsung web browser:


Effect in color change with minimal change from normal user expectations:
Chrome until v80 and lower/Win 7 or macOS (BrowserStack, therefore worse image quality):

No effect (those browsers use different default focus properties):
Edge 17/Win (no change, color differences only due to hover/focus default styles), iOS Safari, macOS Safari:

Change 604945 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/Vector@master] [less] Normalize focus styles in Blink based browsers

https://gerrit.wikimedia.org/r/604945

Looks good. I noticed an edge case in the TOC where a link is generated as an :after element:

My debugger only lets me add :focus to the real element, which generates the correct blue outline, but when I tab through I get black.
This could be a browser bug we can't fix though?

Ha, yes, seems like a browser bug. :focus:after doesn't alter it either. Seems still an acceptable improvement to me with the bug.

Looks good. I noticed an edge case in the TOC where a link is generated as an :after element:

I don't see a link there. It's a <label> with 'pointer' cursor, :after only adds the text "span". The focused element is the <input> checkbox associated with the <label>.
<label>s draw the focus ring when the <input> is focused, the bug is that the :focus styles are not applied in this case.

Change 604945 merged by jenkins-bot:
[mediawiki/skins/Vector@master] [less] Normalize focus styles in Blink based browsers

https://gerrit.wikimedia.org/r/604945

CC @nray @Niedzielski in relation to the sidebar button's focus ring question.

@Demian, the sidebar button is a custom element and is supposed to follow our own WikimediaUI focus styles as seen in OOUI/WMUI theme button demo for example.

Change 607905 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [less] TOC hide link follows the WMUI focus style

https://gerrit.wikimedia.org/r/607905

Change 607906 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [less] "More" Menu follows the WMUI focus style

https://gerrit.wikimedia.org/r/607906

Looks good. I noticed an edge case in the TOC where a link is generated as an :after element:

My debugger only lets me add :focus to the real element, which generates the correct blue outline, but when I tab through I get black.
This could be a browser bug we can't fix though?

The following rule is a workaround:

input#toctogglecheckbox:focus + .toctitle .toctogglelabel {
	outline-color: #36c;
}

Committed: https://gerrit.wikimedia.org/r/607905

"More" menu has fallen victim of the focus ring blackening.
Fix: https://gerrit.wikimedia.org/r/607906

Both patches tested in Firfox and Chrome. The focus outline is consistent with other links in both browsers. Firefox: 1px dotted blue, Chrome: auto (2px solid) blue.

Change 608159 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [less] Add normalized focus ring styles as .mw-focus-outline class

https://gerrit.wikimedia.org/r/608159

Change 608160 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [less] Apply Firefox's dotted focus outline in IE

https://gerrit.wikimedia.org/r/608160

Change 608161 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [modern] Normalize the sidebar button focus ring

https://gerrit.wikimedia.org/r/608161

Demian added a comment.EditedJun 27 2020, 4:48 PM
  • Patch 608159 codifies the normalized focus outline as .mw-focus-outline {} in Vector's 'normalize.less'.
  • Patch 608160 applies these styles universally to :focus, thereby applying Firefox's dotted focus outline in IE.

These styles could be candidate for T256520: Consider 'normalize' stylesheet RL module

DEMO for browserstack.

Focus rings that should be consistent with rings on all other links:

  • Sidebar button
  • More menu (narrow the window to make it appear)
  • TOC hide
Demian moved this task from Incoming to Awaiting Review on the User-Demian board.Jul 5 2020, 5:35 PM
Demian added a comment.EditedJul 6 2020, 12:30 AM

@Volker_E per your feedback - request? - the class has been upgraded to a mixin.

Please note: this "utility" class served the only purpose to be :extend() - ed, NOT to be applied in HTML. As such it does not fall under the pattern of Atomic CSS which concerns what styles are applied.
Basically the implementation was a parameterless mixin to enable entension. The constraint is: pure mixins that aren't output as classes cannot be extended, therefore that solution had to be dropped.
With advanced @import features the "utility" class could be hidden, but I highly doubt those features are implemented in less-php.