Opened 3 weeks ago
Last modified 37 hours ago
#62831 reopened defect (bug)
Bring in lighter background for admin
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 6.8 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Administration | Keywords: | has-patch early |
Focuses: | accessibility | Cc: |
Description
This is one small but strong visual impact that can be made. Let's see how this could look in the attached images on the test site. This uses the white from variables in Storybook in the editor. If this works for everyone, I would recommend bringing in other tickets for more colors. Let's start, though, by seeing what happens if we simply turn things white. We can do a lot more, but this is a start.
Other colors we can start to bring in: https://wordpress.github.io/gutenberg/?path=/docs/tokens-color--page
Attachments (4)
Change History (45)
#2
@
3 weeks ago
Here's a very first workaround which only adds white background everywhere, for early testing purpose:
Try on Playground
To be honest, now I'm used to this white background and I don't want to return to the grey one 😆
#3
@
3 weeks ago
@karmatosed in your screenshot, you also changed the various shades of blue to these proposed in the Figma library. I'm not opposed to this change, but this would also have to happen on Gutenberg side as well.
#4
@
3 weeks ago
@audrasjb thank you so much for the patch. That was using an admin color scheme which brings me to the valid point you mention of using that as a tester, although I do agree that going in with some simple colors works.
This ticket was mentioned in PR #8152 on WordPress/wordpress-develop by @audrasjb.
3 weeks ago
#5
- Keywords has-patch added; needs-patch removed
This is related to https://core.trac.wordpress.org/ticket/62831.
I noticed that the white background was removing the background difference between the welcome panel (the section with a white background).
While it doesn't look shocking to me, this PR also adds a border to the welcome widget.
This is the only issue I found while testing this changeset.
More tests are welcome!
@audrasjb commented on PR #8152:
3 weeks ago
#6
I pushed a follow-up commit to the PR to also use white background on alternative color schemes. Maybe we can choose to keep a grey background on some of them, though.
#7
@
3 weeks ago
- Keywords early added
- Owner set to audrasjb
- Status changed from new to assigned
Adding early
as we want this to be committed asap in the release cycle to provide as much time as needed to contributors to test it in the wild.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
3 weeks ago
@audrasjb commented on PR #8152:
3 weeks ago
#9
@karmatosed do you have any preference for the welcome box? Black border or no border?
That's a detail we can still update later though.
#10
@
3 weeks ago
@karmatosed I'm inclined to commit this change as soon as possible so we can move towards other potential changes, but I just wanted to get a decision concerning the welcome box: should we add borders to this widget or leave it for another specific ticket? What do you think?
#11
@
3 weeks ago
@audrasjb I kind of like it with no border for now. We can always add things in. I like the space. Thank you so much for doing this.
@karmatosed commented on PR #8152:
3 weeks ago
#15
Noting that I am approving this review as did on trac here also. The idea is to remove the border.
#16
@
3 weeks ago
- Keywords commit added; needs-design-feedback removed
Alrighty, we are now ready to ship this first changeset.
#19
follow-up:
↓ 25
@
2 weeks ago
A full white background is known to not be the best color for optimal readability. The best practice is to avoid full white background and full black text. Has this been considered?
#20
@
2 weeks ago
I appreciate minimal/clean interfaces as much as anyone, but I'm slightly concerned about this change.
Without a systematic approach to redesigning WordPress admin, we risk introducing visual inconsistencies—including overwhelming use of borders—not just with core, but for third-party plugins as well.
Such a change might also create challenges for accessibility and plugin compatibility, and it could confuse users who are accustomed to the current interface.
It’s worth considering whether this seeming minor—but in actuality, huge—change provides enough value to outweigh these potential drawbacks.
I don't think so, but I'd appreciate hearing why others do.
#21
@
2 weeks ago
Thank you for your perspective @richtabor. I actually do think it has a benefit and I believe that a gradual approach, doing what we can today is better than waiting for an unset time to do something. Now if we have a set time to do everything then that is different, but being able to gradually make changes does actually benefit usability and improve the experience.
Some smaller changes for the benefit of usability are not a bad thing to do and that is where we need to get to facts. Does this improve or not that. If it doesn't, then absolutely it should come in. If it is a change for better then it should. This moves it out of personal opinion which we both have differences on.
Do you have examples where this change de-grades accessibility? Similar plugin compatibility? It would be great to talk in direct examples and we can review.
#22
@
2 weeks ago
Actually, my personal opinion is that there’s potential here.
I think we’re in agreement there, though I am concerned about the stark borders competing for attention (whereas today they’re notably present, wrapping the contents within— not distracting from). And the widgets, tables, and any element with a differing background color applied to it do loosing prominence, as previously their boundaries were much clearer (with the combined subtle background and border colors).
Where I’m also not fully convinced is that this change makes the WordPress admin experience more usable.
And that this change does not negatively affect any plugins with their own admin pages, components, widgets, etc. Has there been before/afters for these?
#23
@
2 weeks ago
@richtabor one of the key motivations in this was unification between the old and new experiences so as we have time what we could explore is either one of these things:
- Unify with a different tone in both experiences: in table views, other settings/options within the newer experience, white is used. It that is an accessibility concern it is now present in the site editor so should also be resolved. We can do that with a background color fix there too. Let's get both resolved and improved.
- Work also on borders: I didn't do that to try and bring as little destructive a fix in as possible. I am incredibly open to iterations on this patch though.
The work on borders though doesn't address the issue which @afercia you are raising so I would like to have some advise on what tone you would recommend if it's not as dark as the one before.
And that this change does not negatively affect any plugins with their own admin pages, components, widgets, etc. Has there been before/afters for these?
That is the value of early test. We can 100% revert it was done with intention to be discussion not a closed conversation. I again don't mind if we can start to plan on when and how to bring through other pieces. That would be great. This doesn't make or break this release but the longer we don't start unify the worst the experience.
One section that certainly is a vast benefit are settings. Perhaps we can even explore just implementing there if the appetite is more towards that.
#24
@
2 weeks ago
- Keywords commit removed
Thanks for the discussion @richtabor.
Concerning accessibility, it was discussed during the previous accessibility scrub and it was stated that this change wouldn't probably affect accessibility (but we'll want to make it sure during this release cycle).
Concerning third-party plugins, I actually tested about 10 plugins from the top 20 on dotorg, and didn't noticed anything. I think the conclusion of a broader plugin testing analysis whould probably be very close to the conclusion of the tests I made during WP 5.3 Admin Components accessibility redesign: https://make.wordpress.org/core/2019/10/15/report-wp-5-3-admin-css-changes-tested-against-top-20-plugins/ (TL;DR: plugins that use core/native components will adapt fine ; plugins with very custom components or settings pages will probably still override this background color if they already override it today.
#25
in reply to:
↑ 19
;
follow-up:
↓ 26
@
2 weeks ago
Replying to afercia:
A full white background is known to not be the best color for optimal readability. The best practice is to avoid full white background and full black text. Has this been considered?
WordPress doesn't use much full black text and honestly I didn't find any occurrence of full black text on full white background at all in the admin interface (that is, occurrence that wasn't already here before)
#26
in reply to:
↑ 25
;
follow-up:
↓ 27
@
2 weeks ago
Replying to audrasjb:
WordPress doesn't use much full black text and honestly I didn't find any occurrence of full black text on full white background at all in the admin interface (that is, occurrence that wasn't already here before)
It's not just the combination of full black and full white. Even full white alone for the background is known to be non optimal for readability. It could be even hurting for some users. We should avoid eye strain. I'm not opposed to change the admin background but it shouldn't be full white.
If the new design system asks for full white background, well I would srongly recommend t reconsider that decision.
#27
in reply to:
↑ 26
@
2 weeks ago
Replying to afercia:
Even full white alone for the background is known to be non optimal for readability. It could be even hurting for some users. We should avoid eye strain. I'm not opposed to change the admin background but it shouldn't be full white. If the new design system asks for full white background, well I would strongly recommend t reconsider that decision.
Ok but theres a lot of places where full white is used as a background color in the WordPress admin. In the Editor(s) of course, but also in Site Health or Privacy screens… that's also the case on WordPress.org websites, on this Trac tool and on a lot of accessibility compliant websites… and I'm not aware of any accessibility compliance issue with full white backgrounds, and it's not on the Accessibility Team's recommandations (or on accessibility-ready
themes guidelines for instance).
If white background shouldn't be used at all, we should probably make a wider statement on the whole ecosystem rather than just avoiding it on WP Admin screens except for Gutenberg :)
#28
@
2 weeks ago
In my (personal) point of view, given the wide use of full-white backgrounds across web tools and websites, this issue would be better addressed by browser-side appearance settings than websites themselves… That is, as long as the contrasts provided by the website are compliant and as the website doesn't prevent the end-user from overriding its styles.
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
2 weeks ago
#30
follow-up:
↓ 32
@
2 weeks ago
This change really highlights how much work the grey background was doing. 😀
Conceptually, #fff
for body-background is fine, but... every admin screen looks objectively worse now, and is more difficult to scan for what is actionable & important.
I don't think this can be step-1-of-unlimited across multiple releases.
I'm not opposed to change the admin background but it shouldn't be full white.
To me, it looks like a bug – like the CSS of WordPress admin is broken because nothing in the wrap area has any color.
(I just always assume a plugin of mine broke my admin styling, but found this change and ticket instead... 🤣)
Widgets, tables, and any element with a differing background color applied to it do loosing prominence, as previously their boundaries were much clearer (with the combined subtle background and border colors).
Bingo. Especially relative to interactive form elements.
Specifically:
- Border color (for wrappers, boxes, sidebars, & fields) closely match text color (
#8c8f94
vs#646970
and#1d2327
) - Input/select/radio/check backgrounds match the body background (
#fff
) - Button backgrounds are so lightly grey they may as well be white (
#f0f0f1
vs#fff
) - Disabled form elements have more visual emphasis than enabled ones (
#f0f0f1
vs#fff
) - Privacy/Site Health are now white-top, white-tabs, white-body (
#fff
) - Even more oddly, every-other list-table row is emphasized for no real reason (
#f6f7f7
) - Currently active plugins really stand out now (blue:
#f0f6fc
) - Block widgets still have grey background (
#f0f0f0
– why not#f0f0f1
😅) - Old-style H2 tabs still have grey backgrounds (Appearance > Menus, BuddyPress/bbPress,
#f0f0f1
)
If white background shouldn't be used at all, we should probably make a wider statement on the whole ecosystem rather than just avoiding it on WP Admin screens except for Gutenberg
Obviously, there are times & places when bright, vivid, bold colors are the right choice. Most human eyes (mine included) crave contrasting background colors, because real-world things are uniquely colored and we use those differences to gauge base-level concepts like distance, depth, importance, relevance, etc...
If all of WordPress admin body-background is going to be #fff
, there are more than 50 other elements (by my very rough cursory scan of the admin area CSS) that should be targeted and made darker at the same time.
that's also the case on WordPress.org websites, on this Trac tool and on a lot of accessibility compliant websites
All of these use shades-of-grey 👽 on background elements to provide a visual separation, provide emphasis, and draw attention to important sections, areas, and controls – and they all could be better, too.
Ok but theres a lot of places where full white is used as a background color in the WordPress admin. In the Editor(s) of course, but also in Site Health or Privacy screens
Not trying to take a dig at anything or anyone, but the current designs of the Editor and Privacy/Site Health pages include many of their own visual compromises (and bugs) largely attributed to forcing multiple new & unique ideas into the old pages without also fully implementing around existing admin-area APIs (help tabs, list-tables, meta-boxes, etc...) so they are not helping your argument here I don't think 😅
Tangentially, no intention to hi-jack, but I recently used #fff
for the body and something close to #eee
for the bb's Tracs headers & navigations. That's not perfect either, but I think it's an improvement and feedback has been positive... 🩶
#31
@
2 weeks ago
- Resolution fixed deleted
- Status changed from closed to reopened
Reopening as per the comments above. I like the idea of moving to a white background but it needs to be done in conjunction with other changes that allow visual hierarchy, separation, and contrast to be retained. I would also say that just because the block and site editors use white everywhere doesn't mean it's the best solution, they also suffer from a lack of visual hierarchy when the theme uses a white background.
Experimenting is good. This experiment has told us that a more thorough approach is needed.
#32
in reply to:
↑ 30
@
2 weeks ago
Replying to johnjamesjacoby:
Specifically:
- Border color (for wrappers, boxes, sidebars, & fields) closely match text color (
#8c8f94
vs#646970
and#1d2327
)- Input/select/radio/check backgrounds match the body background (
#fff
)- Button backgrounds are so lightly grey they may as well be white (
#f0f0f1
vs#fff
)- Disabled form elements have more visual emphasis than enabled ones (
#f0f0f1
vs#fff
)- Privacy/Site Health are now white-top, white-tabs, white-body (
#fff
)- Even more oddly, every-other list-table row is emphasized for no real reason (
#f6f7f7
)- Currently active plugins really stand out now (blue:
#f0f6fc
)- Block widgets still have grey background (
#f0f0f0
– why not#f0f0f1
😅)- Old-style H2 tabs still have grey backgrounds (Appearance > Menus, BuddyPress/bbPress,
#f0f0f1
)
Thanks for the detailed synthesis! While I don't think text matching border colors is really annoying, you clearly pointed out many really important points to improve.
#33
@
2 weeks ago
Privacy/Site Health are now white-top, white-tabs, white-body
That's a good example and illustrates well how the editor UI and the admin pages are different cases.
The editor is supposed to use the theme's background color for the canvas, unless users disable the preference 'Use theme styles'. For example, Twenty Twenty-Four uses #f9f9f9
. Only the editor UI (top bar, panels, toolbars etc.) uses full white.
As a consequence, in the editor most of the screen will not be full white. Actually, the editor doesn't use white for the canvas, which is the area where users do most of their work. The canvas is white only when the theme uses a white background. So the argument that the editor uses white for the background isn't accurate in the first place. Also, I would agree with @johnbillion that when the theme uses a white background, the editor suffers from a lack of visual hierarchy everywhere because the whole screen is white everywhere.
To me, the admin pages are a different case. Some of the admin pages contain large UIs that mitigate the 'all white' effect. For example: list tables, media library and the like, cover most of the full white background. Although there are still problems as many reported above, in this case the 'all white' effect is mitigated. However, for other admin pages like Settings, Tools, Site health, etc., 90% of the screen is now full white. That's too much strain for the eye. I find myself constantly decreasing my screen brightness since this change landed in core.
that's also the case on WordPress.org websites, on this Trac tool and on a lot of accessibility compliant websites
I would echo what @johnbillion pointed out earlier: just because other wp.org parts use full white everywhere doesn't mean it's the best solution. Also, I would love to see a collective effort to strive not just for WCAG technical compliance. A web page could be technically compliant but not provide the best user experience. Instead, I would love to see WordPress provide the best possible user experience.
Avoiding full white for the background is sort of an industry standard and it's an established best practice since ages. There's research and user testing that validates it and I would love to see WordPress follow the industry best practices instead of reinventing the wheel every time. Experimenting is good and it fuels productive discussions but I'm not sure this change provides the best user experience.
#34
@
2 weeks ago
Avoiding full white for the background is sort of an industry standard and it's an established best practice since ages. There's research and user testing that validates it and I would love to see WordPress follow the industry best practices instead of reinventing the wheel every time. Experimenting is good and it fuels productive discussions but I'm not sure this change provides the best user experience.
I've been working in this industry since more than 20 years and I'm struggling to find any industry standard concerning the use of full white. But I don't know everything :) Do you have any industrial standard reference for avoiding full-white on interfaces? Andrea please note that by asking that, I don't want to diminish your concerns: I really want to know what I missed.
I know there are a lot of studies and research against using too contrasted colors (like #000 on #fff) but that's not what we have here since the font color is not full black. But I'm not aware of any research showing that using #fff as a background color is a bad practice.
#35
@
2 weeks ago
The change is likely a bigger problem than the full-white background itself.
I made the mistake of refreshing a settings page with the new styles and saw the brightness intensify around all the fields. Then my monitor seemed to increase the intensity of white and light backgrounds on other sites. My eyes should have recovered from the shock by now, but the white still is more uncomfortable for me than the gray.
The admin background has been a light gray for many years.
- [26072] added
#eee
(tohtml
) incolors-fresh.css
. - [26788] and [26837] revised the color from
#eee
to#f3f3f3
to#f1f1f1
(`#f3f3f3` was too light then). - [50025] adjusted
#f1f1f1
to#f0f0f1
, using the reduced palette.
Implementation
- [59705] removed the
background
rule entirely. Please define the text and background colors together (onbody
), even if the final decision is to make it white. - Is the timing appropriate? WordPress 6.8 "will focus primarily on being a polish and bug fix release," and this change could require several follow-up adjustments (including #62866 for alternate table rows, removing the background above the Classic Editor, plus anything to make white interface elements stand out more).
- Should this overall effort (re-)start in a plugin, as the (larger) MP6 project had?
#36
@
2 weeks ago
I know there are a lot of studies and research against using too contrasted colors (like #000 on #fff) but that's not what we have here since the font color is not full black.
I'm not sure this is the right way to see the recommendation to not use a full white for the background. Even the white background alone, whatever the text color is, is harmful for the eye It causes eye strain for many users and it's not recommended.
#37
@
2 weeks ago
Even the white background alone, whatever the text color is, is harmful for the eye It causes eye strain for many users and it's not recommended.
That's my whole point: not recommended by who? I'm not aware of any study against full-white. The one I know only point out super strong contrasts like #000 on #fff, and never #fff alone.
Don't worry, we'll probably end up reverting this change… but
At least I would like to make sure we do with a good, rational reasoning. And not just individual perception. If it is industry standard then I'm 100% for reverting this myself. But in fact I never find any industry standard about this in a 20 yo career, so that's why I'm still arguing about this rationale today instead of just reverting that change :)
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
8 days ago
This ticket was mentioned in PR #8298 on WordPress/wordpress-develop by @audrasjb.
38 hours ago
#39
This brings more consistency with the white background.
@audrasjb commented on PR #8298:
38 hours ago
#40
### Before this changeset (using Twenty Twenty theme and Classic Editor and showing default interface)
### After this changeset (using Twenty Twenty theme and Classic Editor and showing default interface)
### Before this changeset (using Twenty Twenty theme and Classic Editor and showing the full interface with all widgets)
### After this changeset (using Twenty Twenty theme and Classic Editor and showing the full interface with all widgets)
@audrasjb commented on PR #8298:
37 hours ago
#41
Note: maybe we can also edit the background colors of the custom fields area, but I'm not sure it's really necessary.
I think it's a good idea to start with a limited scope and iterate during the other releases of the year.
Another option: use an admin color scheme to iterate and make it default later. But honestly, I think the best course of action if probably to iterate directly with the default styles but step by step.
On a triage point of view it would be great to put together a basic PR asap so we can test these colors with as many plugins as possible :)
Adding
accessibility
focus so the team can have a look on these changes, too.