Wpf: High Contrast doesn't work well by default

[clairernovotny]

• .NET Core Version: (e.g. 3.0 Preview1, or daily build number, use dotnet --info)
  .NET 5.0 preview 6
• Windows version: (winver)
  19041
• Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes/No
  Haven't tried/can't try
• Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc...)? If yes, please file the issue via the instructions here.
  No
• Security issues and bugs should be reported privately, learn more via our responsible disclosure guidelines.

Problem description:
Text is not visible after enabling High Contrast Mode. This is a regular WPF app using default themes/settings. It is not doing anything special for High Contrast.

Actual behavior:
Text is not visible after enabling high contrast mode

Expected behavior:
Text should be visible after enabling high contrast mode
Minimal repro:
Install NuGet Package Explorer from Store (or compile from GitHub at https://github.com/NuGetPackageExplorer/NuGetPackageExplorer)

1. Deploy OS.
2. Perform Store Updates.
3. Install the application from Store.
4. Launch the application.
5. Enable High contrast mode.
6. Observe.
   

[miloush]

I don't see how this would be a WPF bug. You are clearly overriding the background of the control to be always white, but you are not overriding the text foreground:

https://github.com/NuGetPackageExplorer/NuGetPackageExplorer/blob/d830786cba9b53dcc54694d60515677a381bee07/PackageExplorer/PackageViewer.xaml#L451

WPF does its job of respecting high contrast and rendering the text white, because the hight contrast background should be black.

Either fix the text color too, or preferably use the control background brush, similarly to how you use the active border brush on the same element. Also note that these resources should be declared as DynamicResoruce not StaticResource so that it changes when the system theme changes.

Or did I miss something?

[clairernovotny]

Thanks -- this is an inherited codebase, I may have missed something and not seen that bit.

[miloush]

No worries. Also it's probably window background brush that you want, not control, sorry I'm mobile, but you get the idea.
I would also reconsider the fancy gradients on the menu...

[clairernovotny]

Any chance you'd like to contribute a PR to address these issues in the NuGet Package Explorer repo?

[rladuca]

@clairernovotny One thing you can also do in your styles, and something we do in WPF, to appropriately differentiate between High Contrast and regular themes is to trigger on SystemParameters.HighContrast. WPF uses the Classic theme in all High Contrast scenarios. However, we need to modify various aspects of that theme when in High Contrast. Below is a just a basic trigger that we use in multiple places to do this.

https://github.com/dotnet/wpf/blob/707c7256e0dd02f2b4cfa3735d457248c66e8d55/src/Microsoft.DotNet.Wpf/src/Themes/PresentationFramework.Classic/Themes/Classic.xaml#L711-L719

So you can have fancier UI for your regular themes (like gradients, specific colors you prefer, etc), but only turn those on when not in High Contrast. That allows you to assume the default WPF colors will do the job and we've worked hard to ensure that in a lot of cases.

Also, a great tool you can use to help find accessibility violations (both in colors and automation tree) is the Accessibility Insights tool.

[clairernovotny]

@rladuca Is there an app config setting or env variable we can apply to the process to force the app into High Contrast mode to test things without enabling it on the whole OS?

I think that would make it much easier for developers to test these modes since folks aren't likely to make OS level changes too often as it's highly annoying.

[rladuca]

@clairernovotny Not to my knowledge (unless I missed some big part of the themes).

While WPF could add something to force load Classic and make it think it's in High Contrast, you'd have to replace all of the SystemColors to match what OS High Contrast theme you wanted to emulate. This is a matrix of both OS version and theme itself and would have to be maintained against OS changes going forward. This is because WPF, mostly, relies on these colors instead of selecting its own explicitly.

It's possible to do this override with XAML from a developer standpoint. I am not aware of anyone who has produced a library to do this, but it doesn't have to be done from within the Framework. See this answer.