Found in

• 106.0a1

Affected versions

• 106.0a1
• 105.0

Affected platforms

• macOS 11
• Windows 10

Steps to reproduce

1. Go to System Preferences => Accessibility (mac) or Settings => Accessibility => Color Filter (win) and set the Inverted Colours option
2. Have the Light theme set at the level os and the System theme - auto enabled inside the browser or enable Light theme from about:addons#themes
3. Observe different buttons/fields (eg. about:preferences page, location/ addon popups, colorways/ printing modals etc)

Expected result

• The background of buttons and fields is distinguishable.

Actual result

• The background of buttons and fields is invisible, only the labels show the presence of each element.

Regression range

• Last good revision: b85e871f6a8d57cdc744634dadb2b0af88422504 (2021-04-06)
• First bad revision: b740f950e4971e9e17c16b0e19e569cd3b07ceb5 (2021-04-07)
• Pushlog:
  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b85e871f6a8d57cdc744634dadb2b0af88422504&tochange=b740f950e4971e9e17c16b0e19e569cd3b07ceb5

Additional notes

• The buttons/fields are visible on hover.

Morgan, is that a high impact bug for a11y?

Hard to say -- we don't have good data on the amount of users who rely on color inverting settings right now. I'll file a bug to add some telemetry :)
The screenshot you added is a direct inversion of the colors we use to render "regular" light mode -- so if our contrast is too low in light mode, it will also be too low with invert colors enabled. Because the inversion is accomplished via display filters (on mac at least, not sure about windows), we don't have the ability to customize how that inversion happens. If we implemented the inverted-colors media query, though, we could add additional styles like borders when we detect a user has invert colors on. I don't have good data on what sort of distinguishing UX is useful to users with invert colors enabled -- I imagine the best way to go about this is to make our general non-inverted UX as accessible as we can, and then have invert colors become more accessible inherently.

For what it's worth, I get a slightly higher contrast version on my screen. I'll attach it. Also, if you enable "increase contrast" with "invert colors", we add defining borders to the buttons which makes them easier to spot. Users shouldn't have to do this, but a work around does sorta exist.

:ayeddi I think you had some experience developing for invert colors in the past -- anything to add here?

The severity field for this bug is set to S4. However, the accessibility severity is higher, [access-s3].
:dao, could you consider increasing the severity?

For more information, please visit auto_nag documentation.

(In reply to Morgan Reschenberg [:morgan] from comment #2)

[...]
The screenshot you added is a direct inversion of the colors we use to render "regular" light mode -- so if our contrast is too low in light mode, it will also be too low with invert colors enabled. [...] I don't have good data on what sort of distinguishing UX is useful to users with invert colors enabled -- I imagine the best way to go about this is to make our general non-inverted UX as accessible as we can, and then have invert colors become more accessible inherently.

Not much to add here and I have the same visual results as Morgan does. It does appear that the low color contrast of controls' backgrounds with the page background is just following the default appearance and is more general a11y concern, independent of the invert colors settings, as was said above.

That's being said, per WCAG 2.1 Success Criterion 1.4.11 Non-text contrast, these buttons are passing, because they (or at least those that I observed clicking around the Firefox) all have specific appearance that communicates to the user that these are, in fact, active UI elements compared to a static text:

• Mostly, this is provided by their position (i.e. far right side of the line, away from an end of a paragraph or a new line altogether, with a white space around their labels) and/or
• by an icon indication (i.e. > or v). Having these icons on the far right side from some labels is a separate discussion, but it is a pass for this Criterion.
• Also, their labels vs their own background provide high color contrast (16:1 for Settings... button in Fx Settings) that keeps them readable for users and is passing the Success Criterion 1.4.3 Contrast (minimum)

(In reply to Morgan Reschenberg [:morgan] from comment #2)

Hard to say -- we don't have good data on the amount of users who rely on color inverting settings right now. I'll file a bug to add some telemetry :)
Did this bug get filed Morgan? That would help prioritize addressing this issue.

It got filed and resolved, yes see bug 1794626

(In reply to Anna Yeddi [:ayeddi] from comment #6)

(In reply to Morgan Reschenberg [:morgan] from comment #2)

[...]
The screenshot you added is a direct inversion of the colors we use to render "regular" light mode -- so if our contrast is too low in light mode, it will also be too low with invert colors enabled. [...] I don't have good data on what sort of distinguishing UX is useful to users with invert colors enabled -- I imagine the best way to go about this is to make our general non-inverted UX as accessible as we can, and then have invert colors become more accessible inherently.

Not much to add here and I have the same visual results as Morgan does. It does appear that the low color contrast of controls' backgrounds with the page background is just following the default appearance and is more general a11y concern, independent of the invert colors settings, as was said above.

I agree that's the right way to look at this. So rather than using the inverted-colors media query, I think we should look into:

• adding a border (doesn't need to be as visible as in high contrast mode), or
• making the background a more opaque (might be tricky as about:preferences needs this to work on different shades of gray behind the button)

As this is a general a11y concern and not limited to inverted colors, I'll increase the severity to S3.