Some template level svgs are hard to see when using forced colour browser extensions

[owenatgov]

Description of the issue

When using certain forced colour made browser extensions, in this case Dark Reader which changes colours by rotating hue, certain in-page template svgs like the GOV.UK logo lockup and the OGL logo in the footer incorrectly change with the colour mode, making them functionally impossible to see with the

Steps to reproduce the issue

1. Go to a GOV.UK service on a browser with Dark Reader installed, with Dark Reader turned off
2. Scroll down to the bottom of the page, note the OGL logo in the footer
3. Turn Dark Reader on

Actual vs expected behaviour

Expected

The OGL logo is the same colour as the page's text colour, forced or otherwise eg: it'll be black if text is set to black, white if text is set to white.

Actual

The OGL logo is an off-black against the dark footer background

Environment (where applicable)

• Operating system: MacOS Tahoe 26.4.1
• Browser: Chrome
• Browser version: 147.0.7727.117
• GOV.UK Frontend Version: >= 5.14

Notes

What seems to be happening here is Dark Reader is adding attributes to change the colour of the SVG by rotating it's hue 180 degrees. At least for the OGL logo, this is overriding the fill="currentcolour" applied to the path of the OGL svg. That attribute is setting the svg to the page text colour, which the extension is overriding back to black.

Removing fill="currentcolour" resolves this and, from some very shallow testing, seems to work fine without any forced colours and with other forced colour methods. It looks like there are some team tasks to do here:

1. Decide if this is something we want to try to figure out at our level or if we call this a bug in Dark Reader instead and not make it our concern
2. Investigate if removing fill="currentcolour" causes other unexpected problems
3. Try to understand Dark Reader's behaviour further and if there's something we're doing that's triggering Dark Reader to apply that hue rotation styling

[querkmachine]

My immediate concern is that this is an issue exhibited by a browser extension. If it were a system dark mode or forced colour mode, or first-party browser feature then I'd feel more beholden to us doing something about it, but for a third-party extension, going out of our way feels... iffier?

Would we then be making a statement that we think fixing it in Dark Reader is worth the effort but a bug that exists in My Other Dark Mode Extension isn't?

I think the extent of our involvement here might be to report it to whoever makes Dark Reader and hope they fix it on their end, especially as it seems to have some capacity for per-site fixes. This bug report might also be related.