Change font weight of settings and other similar labels

[karmatosed]

This is part of the unification work I am looking to work on for this release, hence putting for that milestone, this can be punted, moved and adjusted as others see fit.

In the wp-admin these labels are set to 600. However in the site editor and Storybook guide it is 500 or 400 depending on use case. You can also see this throughout the editor. There are other variations including uppercasing. My recommendation is that we do the following:

• Keep the larger font size. In the site editor there is a smaller 13px one, but for settings the 14px is not something to reduce, particularly for usability if also are looking to increase the input and buttons.
• Don't use uppercasing because for a few labels there are multiple words. This can cause accessibility issues and legibility problems.
• Reduce to either 500 but ideally 400. What this does is stop the significant visual 'smudging' that the heavier 600 brings visually to labels. The idea is to aid readability as a result for everyone.

I have attached some mocks of what this results in and also would like feedback on how extensive this should be along with options for improving.

[audrasjb]

A comparison between font-weight 600, 500 and 400

[audrasjb]

I tried both 500 and 400, and at first, 400 felt really light. But once I got used to the new look, I have to admit that it actually works pretty well.

[karmatosed]

@audrasjb thank you for testing. I agree that it takes a little while to adjust, mostly because we are so used to it. Once you do there is the clarity back which to me feels really positive.

This lightens up the font weight from 600 to 400.

Trac ticket: https://core.trac.wordpress.org/ticket/62865.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request.
See ​GitHub Pull Requests for Code Review in the Core Handbook for more details.

This changeset looks good to me 👍

I have some other changes to propose, but I can add a follow-up PR.

[audrasjb]

In 59709:

Administration: Use a lighter font-weight value for settings labels.

This changeset lowers the font-weight value from 600 to 400 for labels located in the Settings screens.
This is an initial implementation of the WordPress design system, aligning with the broader goal of achieving a more consistent and unified design across the administration.

Props karmatosed, audrasjb.
Fixes #62865.

[audrasjb]

Reopening for follow-up changes.

https://core.trac.wordpress.org/ticket/62865

I didn't open a new ticket for this one as it is directly related to settings screens… but we can still open a ticket if needed :)

Before:

After:

Ha… this also updates dashboard widget's font-weight BTW :)

[audrasjb]

Given this PR also updates other screens, should I open a specific ticket for headings @karmatosed? What do you think?

Or should we keep this ticket to address all the font-weight changes in 6.8? Both of the options sound good to me.

[karmatosed]

I don't mind @audrasjb. I guess the conversation is valid here. It shouldn't update too much beyond table headers. What we likely need is an accessibility check we haven't gone a bit too far in also changing them for card headings. I personally feel it helps even with those but I don't want to presume as that is never the best.

[afercia]

I would like to see this change be checked and considered from an accessibility perspective.

Also important: I would like to see it checked on Windows, as the macOS font rendering engine is known to render the fonts weight a little 'bolder' than what other operating systems do. To me, the 400 font weight is too light on macOS already and I guess it ends up to be definitely too light on Windows.

On a general note: I'd think this kind of small but very impactful changes should be considered with more caution and be discussed more broadly instead of being proposed and committed in less than 2 days. Personally, I was unaware this change was planned. The fact this proposed change comes from the new design system is certainly important but it doesn't mean it should be committed without allowing broader discussion because I'm not sure the new design system has received broad feedback and had the necessary visibility, so far.

Cc @joedolson can this be discussed in the next accessibility bug scrub>

[karmatosed]

@afercia thank you for your input. I don't think anyone in this ticket is saying that accessibility shouldn't have strong input that is why from the start I added the labels to ensure reviews happened. Let's do that and move forward with whatever works for everyone.

I will say as someone with visual and processing issues such as dyslexia, fonts that are bold are incredibly hard for me to read and the current solution was blurry. I personally find the patch helped. That doesn't mean of course it doesn't cause issues for other cases as with anything this is a balance and we wanted the input of experts. Thank you, let's collaborate.

[afercia]

@karmatosed thanks for your feedback. I did see the accessibility label was used on this ticket, thanks for that. However, I'm not seeing any specific accessibility feedback has been given on this ticked or the related PR on GitHub.

Opening a trac ticket isn't just a formal act to be compliant with the contribution process. Instead, it serves the purpose to gather feedback from the broader community of contributors. Creating a ticket and committing a change in just (more or less) 36 12 hours doesn't allow for some broader discussion, in my personal opinion. That said, any change can be iterated on or even reverted if need be but I'd still think allowing for some more discussion before committing changes is the best way to have a higher quality end result.

Certainly, lighter text may help some users. But even in the realm of dyslexia other users may benefit from the opposite case by shapes that are thicker. For example, some font faces specifically designer for (some types) of dyslexia use a heavier, bolder line thickness that emphasizes the bottom of most letters. This is the case for the Dyslexie font face, for example. One more font face recommended for (some types) of dyslexia is the much reviled Comic Sans, which does use ticker shapes. As you know, there's not just one type of dyslexia and there is no single font or weight that can help all users.

Other kind of low vision may suffer from a reduced font weight. For example, for me the labels are now _less_ visible.

Until users will be able to customize the font metrics, we need to find a balance that helps the largest audience. Also, I'd still like to see this change checked on Windows, where I will the 400 weight ends up being too thin.

Overall, I think this change should be considered more carefully to ensure that the user interface does not introduce a worsening of readability for many users.

[audrasjb]

Hello @afercia, I just wanted to note that I tested the change on both Windows and Mac OS. While the change is looking quite thin (like I said in my first comment in this ticket), I didn't find major readability issues.

But yes a broader user testing phase is of course definitely useful. By the way, it's also a benefit of committing this change early in the release cycle: people running the nightly build can now view this change and report any issue.

[sabernhardt]

lighter weight on Discussion Settings screen, at about 600 pixels wide, with Windows 11 and Firefox

[sabernhardt]

Media Settings screen also groups settings under a table header

[sabernhardt]

the table header font-weight affects Profile screens

[audrasjb]

Thanks for the screenshot. This looks like good readability to me but other thoughts are welcome.

[joedolson]

The most significant problem I see here is that there is no longer a distinction between labels and descriptive text near labels.

I'm not sure that readability is the most important question here; it's whether the labels stand out appropriately as distinct from surrounding context. As long as the text meets the same criteria as body text in the admin, then it should be readable; but it also should be distinguishable from non-label text.

[audrasjb]

You definitely make a point here @joedolson, the sole distinction between label and field description is their color. While the WordPress Admin has a other instances of labels that don't differ (at all) from field descriptions, we should probably explore a better way to distinguish these.
Using font-weight: 500 rather than 400 would indeed provide a clearer visual distinction, instead of just using a different color.

Also, I noticed that the block editor uses font-weight: 500 for several instances of labels.

[afercia]

@joedolson makes a good point. As a low vision user, in some of the admin pages I now see a wall of text where labels, descriptions, and other text are less distinguished. Good use of font weights establishes a typographic hierarchy and as some of the screenshots above illustrate, any hierarchy is now gone.

However, I do think it's also about readability. For low vision users, contrast is very important. A bolder font weight inherently provides higher contrast (that's the reason why the WCAG contrast requirements establish a lower threshold for bold text).

It's not just about the the mathematical calculation of the colors contrast ratio. It's about how a color pair contrast is actually perceived and the font weight is an important factor. With the same colors, bolder text is perceived as higher contrast compared to lighter weight text because the thicker shape helps a lot. As such, making labels thinner isn't an improvement also in terms of contrast and readability.

Also, I noticed that the block editor uses font-weight: 500 for several instances of labels.

I would recommedn to increase that to 600 because 500 on Windows is really too light. Traditionally WordPress always used 600 for bold.

[audrasjb]

In terms of perception, I personally find thicker shapes more difficult to read by the way… like as if it was un bit blurry. I find it more readable with weight 400 or 500… That said, I don't want WordPress to suit my personal needs but rather to implement something compliant with the actual accessibility rules/recommandations.
It's hard to make decision based on our personal perception so it would be nice to start with state of the art recommandation :)

[afercia]

It's hard to make decision based on our personal perception so it would be nice to start with state of the art recommandation :)

Right , and that's my point. Research, WCAG recommendations and best practices establish that bolder text is more readable results in higher contrast for the vast majority of users. Reducing the perceived contrast isn't an improvement.

[audrasjb]

As per today's accessibility team bug scrub:
We are going to iterate on this change to see whether a thicker weight (500 or 600) improves the interface, and also explore increasing the font-size with a thin weight like 400 does the job.

[joedolson]

I've been thinking about ways to objective describe the actual change in readability by moving from 600 weight to 400 weight. This isn't accounted for in WCAG, so it requires some creative thinking.

I think we can use a scalar proportion that uses the large-scale definition in WCAG to assess how this has changed in objective terms.

Defintion: large-scale: 14pt/19px and bold or 18pt/24px at normal weight.

Proportion in WordPress 6.7: 14px bold = .74 of large scale

Proportion with this change, at 400 weight = .58 of large scale

WCAG doesn't account for scalar bold values, so going to 500 weight is fuzzy. But we might consider it halfway between normal and bold, e.g. .66 of large scale.

If we want to achieve the equivalent degree of visibility in terms of proportional contrast, we could target meeting the same scalar saturation.

• At 400 weight, that would mean we need 18px.
• At 500 weight, using the same assumption above, we'd need 16px.
• At 600 weight, no change is required.

At those weights, the *technical* objective of keeping the same degree of contrast might be met.