This chapter is from the book
This chapter is from the book
This chapter is from the book
Making the App Accessible
XAML apps have a number of accessibility features built in, designed to help users with disabilities. You can test this support by enabling various features in the Ease of Access section in the PC Settings app. You can configure Narrator, a screen reader, and witness it convey information about your app with varying degrees of success. (You can quickly toggle Narrator on and off by pressing Windows+Enter.) You can choose a high contrast theme and watch controls used by your app automatically change to match the theme. You can turn off standard animations. And so on.
The Windows SDK includes several tools that help you ensure that your app is accessible. The most important one is UI Accessibility Checker, which reports missing accessibility information in your app. Others are Inspect, which is a viewer for accessibility data on your elements, and Accessible Event Watcher, which focuses on the accessiblity events that should be raised.
To make your app usable to the broadest set of customers, including people with disabilities, you should take steps to ensure it works even better with these assistive technologies. In this section, we look at improving the screen reading experience for our HelloRealWorld app, and accounting for high contrast themes.
Improving Screen Reading
If you turn on Narrator and launch the HelloRealWorld app (with English as the Windows default language), you hear the following:
- “HelloRealWorld window”
- “Editing”
The first utterance is triggered by the app’s window getting focus, and the second utterance is triggered by the TextBox getting focus (which happens automatically).
This experience isn’t good enough, because Narrator doesn’t report the purpose of the TextBox. To fix this, we need to leverage the UI Automation framework, which is as simple as setting the following automation property on the TextBox:
<TextBoxAutomationProperties.Name="Please enter your name"Name="nameBox"Margin="12"/>
If you add this property then rerun HelloRealWorld with Narrator on, you will hear the following:
- “HelloRealWorld window”
- “Please enter your name”
- “Editing”
Note that when you give the Go Button focus, such as by pressing Tab, Narrator says:
- “Go button”
This works automatically, thanks to built-in Button behavior that reports its content to the UI Automation framework.
When you click the Button, however, Narrator gives no indication that text has been added to the screen. If a message is worth showing, then it’s worth hearing as well. To fix this problem, we can add the following automation property to the result TextBlock that identifies it as a live region:
<TextBlockAutomationProperties.LiveSetting="Polite"Name="result"FontSize="28"Margin="12"/>
A live region is an area whose content changes. This AutomationProperties.LiveSetting property can be set to one of the following values:
- Off—This is the default value.
- Polite—Changes should be communicated, but they should not interrupt the screen reader.
- Assertive—Changes should be communicated immediately, even if the screen reader is in the midst of speaking.
Live region changes are not detected automatically, however. You must trigger them in C#. In our example, we just need to add an extra line of code to the existing Button_Click event handler:
voidButton_Click(objectsender,RoutedEventArgse) {this.result.Text =this.nameBox.Text;// Notify a screen reader to report this textTextBlockAutomationPeer.FromElement(this.result).RaiseAutomationEvent(}AutomationEvents.LiveRegionChanged);
TextBlock, as with other controls, has a peer class in the Windows.UI.Xaml.Automation.Peers namespace. These classes are named with the pattern ElementNameAutomationPeer, and have several members that are designed for accessibility as well as automated testing.
After the work we did to localize the HelloRealWorld app, it would be unfortunate to give screen readers a hardcoded English string, as shown earlier:
Fortunately, automation properties can be localized just like any other property. To do this, remove the explicit setting and give the element an x:Uid:
Handling High Contrast Themes
The built-in controls automatically adjust their appearance when the user enables a high contrast theme. They adjust their colors to match the theme’s eight user-customizable colors, and in some cases they change their rendering in other ways. Because of this, your app can automatically look correct under a high contrast theme without you doing extra work. However, when you use images or hardcoded colors, which are quite common, problems arise. Images can be a problem when they convey information but do not use enough contrast. Hardcoded colors are a problem for the same reason, but also because they can make things completely unreadable when intermixed with colors that drastically change under a high contrast theme. In general, mixing hardcoded colors with dynamic colors can be a recipe for disaster.
HelloRealWorld doesn’t use any images, but Chapter 13 explains how you can provide separate versions of your images that can be used for high contrast themes only.
For HelloRealWorld, the hardcoded blue (or red or green) background color could be problematic as the colors of the other elements change. (Although none of the high contrast themes use blue, red, or green as a text color by default, the user could always choose it for the color of text.) We can fix this in code-behind by checking whether the app is running under high contrast and simply removing the StackPanel’s Background in that case:
publicsealedpartialclassMainPage:Page{BrushdefaultBackground;publicMainPage() { InitializeComponent();// Save the default background for laterthis.defaultBackground =this.stackPanel.Background;AccessibilitySettingssettings =newAccessibilitySettings();// Update the background whenever the theme changessettings.HighContrastChanged += OnHighContrastChanged;// Set the background appropriately on initializationOnHighContrastChanged(settings,}null);voidOnHighContrastChanged(AccessibilitySettingssender,objectargs){this.stackPanel.Background =sender.HighContrast ?null:this.defaultBackground;}... }
Because the user could change the theme while our app is running, we need to handle the HighContrastChanged event to adjust accordingly. The rest of the app’s elements already adjust automatically. Figure 1.14 shows the result of adding this code then running the app under two different high contrast themes. Chapter 18 explains how you can define theme-specific colors without needing to write C# code such as this.
)
FIGURE 1.14 Removing the explicit StackPanel background makes the app look appropriate under any high contrast theme.
By defining and using the defaultBackground member, the code that handles the HighContrastChanged event preserves the language-specific background color that comes from one of the Resources.resw files. It does so without needing to programmatically retrieve the current resource value. However, if you need to do so, you can use code like the following for the Panel.Background value:
If you do the following:
- check that the Windows SDK accessibility tools have no high-priority complaints about your app
- verify that your app acts appropriately when using Narrator
- verify that your app acts approrpiately when running under high contrast
- verify that your app can be used when navigating using only the keyboard
then you should take credit for your work and check the “My app meets accessibility guidelines” checkbox within your app’s listing in your Windows Dev Center dashboard. This fact gets advertised in the Windows Store, and it makes your app shows up for users who search for accessible apps.