I think this is caused by a regression that has been documented upstream: https://gitlab.com/gitlab-org/gitlab/-/issues/386736. Fixing looks to be bogged down in discussions of UX reviews and component creation rather than just figuring out which css rule was removed/replaced as part of adding dark/light mode support.

Adding custom css to the site is a long requested feature upstream. Some extremely industrious users have documented nginx proxy hacks to inject custom css & js into each page. There are other clever workarounds documented in the feature request as well, but they generally look fragile.

For what it's worth, GitLab admins can adjust the messages here:

https://gitlab.wikimedia.org/admin/broadcast_messages

(Edit: Sorry, I see that was already mentioned in the description.)

I think the "light" theme (#4) seems like the best of a bad set of choices until this is fixed.

In T330496#8644707, @bd808 wrote:

I think this is caused by a regression that has been documented upstream: https://gitlab.com/gitlab-org/gitlab/-/issues/386736. Fixing looks to be bogged down in discussions of UX reviews and component creation rather than just figuring out which css rule was removed/replaced as part of adding dark/light mode support.

Bryan you are a hero. The issue is due to dark/light mode indeed. If I head to my user preferences ( https://gitlab.wikimedia.org/-/profile/preferences ) and switch the color theme to Dark Mode (alpha), the banner messages are readable:

TADAM

The text has a light class with color #ececef which comes from some "dark" css.

However when using the Light Grey color theme, the text has a a light class with color #333238 (so even darker than in dark mode).

Anyway, I am happy to see there is an issue reported Upstream. I think that is good enough for my case and I assume that will eventually be fixed. We can close our task, unless we want to keep a copy open here.