Some widgets use low contrast background when high contrast mode is enabled
The high contrast mode adds borders around various widgets such as text entry and buttons to make them easier to distinguish from the background, but it does not increase the contrast of text in the widgets, even though increasing text contrast is an important part of what high contrast mode should be doing.
The issues I’m pointing out here could be considered accessibility regressions, when comparing an application using libadwaita to an application with similar design using the the Gtk3 “HighContrast” theme.
All examples here are using Light mode, but I believe the problems exist in dark mode as well. I’m using the file chooser window for my examples - it’s a window that I see a lot, and it’s unlikely to be affected by application-specific CSS, so my comments should apply only to libadwaita.
Buttons
First, the text in the “Cancel” button is unnecessarily low contrast. Removing the background shading helps a bit:
But this still isn’t as good as the “HighContrast” theme when the button is placed in an area with a shaded background, like a headerbar. In HighContrast, all buttons have opaque backgrounds, so the text contrast in the button is the same regardless of what the button is placed over top of. If using an opaque background for high contrast buttons is not an option, then shading the button background lighter - for example, here I made the background rgba(255,255,255,0.7)
- is an alternative to consider.
Alice brought up a concern regarding button colouring and shading buttons lighter - here's my thoughts on that:
- Removing the button background shading to increase contrast removes the button colour from the background anyways, so shading the button lighter with a neutral colour is unlikely to make things worse.
- Since the button colour is used for the border, the application’s chosen button colour remains visible even when the background colour is removed.
- Coloured text has less contrast than black text, so using a higher contrast neutral background is more important for coloured text.
- The button hover state should probably still have a coloured background.
Text Entry
With the border added, the grey background is unnecessary to distinguish the text entry field. It can also have its background shading removed:
Similar to the case of the button, the text entry also has the issue where its contrast varies depending on the background it is placed over. Using an opaque background or shading the background lighter with a neutral tone would help here as well for text entries located in a header bar or dialogue window.
Selections
Finally, I have some thoughts about selection colour. From discussions with Alice in GNOME Design chat, it sounds like the selection background colour is set to a low contrast transparent blend as a way to work around an issue with Gtk where links in e.g. Label widgets which support text selection do not get recoloured to the selected text colour, but are instead left as unreadable blue-on-blue.
Note that Gtk4's "HighContrast" theme still uses dark blue with white text for selections in a few widgets - the tree view in the inspector is a notable case, oddly enough - but this was probably an oversight.
I'd argue that in the case of the High Contrast mode, and given that the majority of selections seen in Gtk applications do not include links, using white text on coloured background for selections is overall beneficial, but this needs some design feedback, and there might be an alternative design possible for high contrast selections which still avoids this issue.
The issue with links could also be fixed from the Gtk side by ensuring links in selected text use the selected text colour instead of blue; doing this would match the behaviour of both Firefox and Chrome.