Follow-up #1: Does the approach taken for using a particular high contrast system color in a UWP HTML app also work with a web page in a browser?


This post describes a question arising from the discussion detailed at More tips on building accessible Windows apps, including a couple of things introduced with the Windows 10 Anniversary Update.

 

I recently built a UWP HTML demo app with CSS to specify that when a high contrast theme is active, the text on a button should be shown using the system color for button text.

 

@media screen and (-ms-high-contrast)
{
    .crimsonKing {
        color: ButtonText;
        border: solid;
        border-width: 1px;
    }
}

 

(I also deliberately show a border in high contrast too. I felt that clear visual delimiters between elements in the UI would be helpful when a high contrast theme is active.)

 

I then wanted to see if this CSS would achieve what I wanted when the HTML page was loaded directly in the Edge browser. So I set the High Contrast Black theme to be active and then the High Contrast White theme, and also ran the test described at A tip on how to find some high contrast bugs.

I found that the visuals shown in the buttons did respect the system color from the active high contrast theme, and also that Edge reacted to the change in state of theme while the page was loaded, so I didn’t have to refresh the page whenever high contrast changed.

If this was a shipping app, I’d also test the button visuals with each theme active, as the state of the element changes. For example, as it gets keyboard focus, becomes selected, or as the mouse moves over it. Sometimes an element with custom visuals can look fine when a high contrast theme is active until you move the mouse over it – and then it vanishes.

The images below show the demo app with different themes active.

 

Demo app page loaded in Edge with the default Windows theme active.

Figure 1: Demo app page loaded in Edge with the default Windows theme active.

 

Demo app page loaded in Edge with the High Contrast Black theme active.

Figure 2: Demo app page loaded in Edge with the High Contrast Black theme active.

 

Important: If the High Contrast Black theme was the only high contrast theme that I tested the UI with, then I would think the UI was great based on the results shown in Figure 2. But if the button text had actually been hard-coded to white, then the button’s content might become invisible when other themes are active, and I wouldn’t be aware of the problem. Instead, someone would test the app with the High Contrast White theme just before the app was due to ship, find the UI isn’t accessible with that theme, and everyone then freaks out. So test with both the High Contrast Black and High Contrast White themes early during development.

 

Demo app page loaded in Edge with the High Contrast White theme active.

Figure 3: Demo app page loaded in Edge with the High Contrast White theme active.

 

Demo app page loaded in Edge with a high contrast theme customized as described at the blog post "A tip on how to find some high contrast bugs."

Figure 4: Demo app page loaded in Edge with a high contrast theme customized as described at A tip on how to find some high contrast bugs.

 

All in all, the snippet of CSS seems to do just what I need in both my UWP HTML app, and also when the page is loaded directly in Edge. If I can find a recent MSDN page that shows the mapping between all the customizable theme colors and the system colors specified in CSS, (eg “ButtonText”,) I’ll add it to this post.

Guy

 

Posts in this series:

More tips on building accessible Windows apps, including a couple of things introduced with the Windows 10 Anniversary Update

Follow-up #1: Does the approach taken for using a particular high contrast system color in a UWP HTML app also work with a web page in a browser?

Follow-up #2: How do I have access keys shown on buttons in my UWP XAML app?

Follow-up #3: How can I increase the visibility of keyboard focus feedback in my UWP XAML app, without having to write custom visuals?

Follow-up #4: Can I customize the path that the Narrator screen reader takes when moving to the “next” or “previous” element in my UWP app’s UI?


Comments (0)

Skip to main content