Xamarin.Forms and MAUI app Accessibility

Note: Some users who installed XamRight recently (about May 22 – June 7, 2023) had their trial period end early (often within a day). If this happened to you, install the latest version from the marketplace (XamRight 4.2 or later) to automatically have a new trial period start, or contact us for assistance.

There are many good reasons to consider accessibility in app development — including reaching more users and complying with governmental regulations. Microsoft has an interesting and detailed writeup with their commitment to accessibility.

When it comes to developing apps, there are many things to consider in accessibility, including high-level UX design. This post focuses on just two important areas of accessibility: content descriptions for screen readers and color contrast can be addressed by appropriate use of Xaml properties.

We include examples of warnings generated by XamRight as examples of the kinds of problems you’ll need to address, but whether or not you use XamRight, we hope these examples will help you on your journey to building accessible applications.

Supporting Screen Readers

Screen readers are a form of assistive technology that render text content to speech. They are essential to users with visual impairments who cannot rely exclusively on understanding what’s on the screen.

Xamarin.Forms and .NET MAUI have been getting better at providing reasonable default behavior for screen readers, but there are still gaps in how these defaults work with screen readers in terms of clearly presenting all of the information and options available. The app might be usable, but users who cannot see the screen will have a very poor experience.

There are several properties available that guide screen readers to give a better experience. These properties are part of the AutomationProperties class and the SemanticProperties class in .NET MAUI, which map to the native accessibility API on Android, iOS and Windows and give you more control over how screen readers would treat elements in your user interface.

The most commonly used properties include:

• AutomationProperties.IsInAccessibleTree – a boolean that determines if an element is visible to screen readers. Note that guidance for using the property has changed in .NET MAUI and in general is not needed. The most common controls that needed IsInAccessibleTree to be set in Xamarin.Forms no longer need this set in MAUI.
• AutomationProperties.Name – a short, descriptive text string that acts like an identifier for the element when it is read. For .NET MAUI, SemanticProperties.Description is preferred.
• AutomationProperties.HelpText – a longer description of the element. For .NET MAUI, SemanticProperties.Hint is preferred.
• AutomationProperties.LabeledBy – allows another element to describe accessibility information for the current element, using the x:Reference markup extension in Xaml. For .NET MAUI, using Binding with SemanticProperties.Description is preferred.

XamRight provides guidance on when to use these AutomationProperties for elements in Xaml code so you can eliminate some of the most common accessibility issues.

For example, it can suggest setting AutomationProperties.Name or HelpText on selectable controls such as Button, reminding you to describe their function for the benefit of screen reader users. Without additional context, a user with a screen reader might not understand why they would click “Ok”.

XamRight also detects when you have views such as Image that need to enable AutomationProperties.IsInAccessibleTree in order for screen readers to focus on them. It can set this property for you in one click too, so you can save time typing. Note that by default, Image is included in the accessibility tree in MAUI, so the main reason for AutomationProperties.IsInAccessibleTree in MAUI would be to set it to false for purely decorative images.

There are a lot of code-level decisions that can make or break your app’s accessibility, such as selecting controls that don’t support AutomationProperties, like EntryCell, which makes it impossible to make this aspect of your app accessible. Instead, you would need to rewrite the EntryCell to a more accessible alternative implementation.

Drag/swipe gestures can be problematic for accessibility; people with visual or motor disabilities find them challenging to use. These should be handled carefully to make sure there is an alternate, accessible way to access that functionality.

The exact behavior of a screen reader depends on the device, implementation and use case and so it is recommended that you always test your app manually with a screen reader. However, like with many other kinds of bugs, using static analysis tools like XamRight shortens your testing cycle.

Color Contrast

All users can benefit from good color contrast in an app: people with low vision and color blindness may have a hard time seeing the difference between colors that are too similar, but even fully sighted people can get frustrated trying to read content with poor color contrast.

There are clear standards for color contrast defined by the Web Content Accessibility Guidelines. All of the color choices in your application, both in Light Mode and Dark Mode, will affect the color contrast as seen by users. See this post for a more in-depth look at the details of Dark Mode and Xamarin.Forms.

While color contrast is important to understand for all elements of your UI, XamRight focuses on text color contrast. Unfortunately, the defaults for Xamarin.Forms and MAUI controls don’t always provide good contrast in both Light and Dark Mode by default.

The color displayed on the screen is a combination of platform defaults, Style resources and properties on elements of the Xaml tree. Since XamRight analyzes all of the Xaml files in an application, it is able to compute color contrast when it sees color properties like TextColor, DetailColor and BackgroundColor set on elements and pages.

Conclusion

Developers may think of accessibility features as something optional, but it’s really in everyone’s best interest to implement them. You will improve how people with disabilities experience your app and make your app inclusive of more users. In a growing number of places, making applications accessible has also become the law, but you don’t need to wait for that to happen before you begin thinking about accessibility.

While this post focuses on two key areas of accessible app development, there are additional ways to improve accessibility, including more platform features and UX design. However, content labeling and good color contrast are important foundations for any accessible app developer to understand.

If you have a Xaml-based Xamarin.Forms or MAUI app, the accessibility checks in XamRight are a great place to get started today!