Microsoft Accessibility - Part 1: Introduction

This series of blog posts tries to look at Microsoft Accessibility from a developer's point of view - making sure your product works well with assistive technologies like Windows Narrator. The focus is primarily on native developers - C++/MFC/Win32,etc.

Here is a how Microsoft defines Accessibility.

"... enables Windows applications to provide and consume programmatic information about user interfaces (UIs). It provides programmatic access to most UI elements on the desktop. It enables assistive technology products, such as screen readers, to provide information about the UI to end users and to manipulate the UI by means other than standard input. UI Automation also allows automated test scripts to interact with the UI"

Accessibility is a way by which other software can read and understand what is displayed in your window. This is used in assistive technology products like screen readers, and for running automated scripts on your application (eg. for automated UI testing).

Significance of having your application support accessibility technologies

When talking about assistive technologies people often imagine (erroneously) users which have severe disabilities - like complete loss of vision. Accessibility pertains to a wide range of people with a wide range of abilities, not just the folks with disabilities^([1]). Another fallacy is to assume that people who need such technologies are only a small fraction of your overall user base (The myth of the minority user). They can constitute more than 50% of your userbase. Here are some data from Forrester Research 2004 study^([1]).

1. 44% of computer users use some form of assistive technology
2. 57% of computer users could benefit from assistive technologies
3. 1 in 4 people experience visual difficulties
4. 1 in 4 experience a pain in wrists or hands
5. 1 in 5 experience hearing difficulty
6. 57 million users of accessibility technologies in 2003, and it was only expected to grow year on year.

Such data are an eye opener. Not only the people needing assistive technologies is not small, they constitute a big fraction of all computer users. Additionally, many countries have laws which make it mandatory for your software to support various forms of accessibility (see this, and this - Minimize Legal Risk). Norway for example fines commercial websites which fail to support accessibility^([2]).

Thus the time and money you invest in making your product accessible will be worthwhile.

Microsoft accessibility frameworks - Active accessibility, and UI Automation

MS has had native support for accessibility frameworks since Windows 95 days. As of now there are two main frameworks - Microsoft Active accessibility (MSAA), and UI Automation (UIA). Active accessibility is the older framework, which has been there since Win95 days. UI Automation is the newer framework release in 2005 with Vista, and tries to overcome limitations of MSAA. MSAA is simpler to implement, but is also limited in features and performance. If your software supports neither, and you are beginning to support one of these, it is better to implement UIA. Note that the same software if needed can implement both MSAA, and UIA.

See this - Microsoft Active Accessibility and UI Automation Compared

The focus of this series of articles will be mainly UIA.

How to support UI Automation (UIA) framework - add support for accessibility

For win32 applications to support accessibility they have to implement various COM interfaces, and specify certain properties. For instance there is one COM interface which allows an assistive technology (AT) like Screen reader to read the name of a button (IRawElementProviderSimple::GetPropertyValue()), there is another interface which allows an AT to click the button (IInvokeProvider), there is an interface which allows an AT to read, and set values in a text control (IValueProvider), and so on. These interfaces are also known as patterns. MS maintains a mapping of control type, and patterns it must support (See this). It is these mappings which are checked by tools such as Accessibility Insights. Properties are certain pieces of data associated with a control which describe it, like name, type of control, etc. While Patterns are interfaces and methods callable on a control, properties are like name-value pairs of data.

Consider the following image which shows info shown by Accessibility insights for a Dialog based MFC application's "OK" button.

Name, ControlType, etc. are the properties. The Patterns which the control supports are listed in the bottom pane.

Native win32 controls have these patterns, and properties implemented by default. Hence when using Win32, or MFC you will seldom have to tinker with accessibility related stuff. There may be times when the support provided by default isn't enough - say a pattern is missing or a property is not set correctly. You may also have a custom control in your application, which will require the accessibility interfaces to be implemented explicitly from scratch.

In the next few posts we will be diving deeper into some of these concepts.

References

1. Engineering software for accessibility (book)
2. https://www.w3.org/WAI/business-case/#minimize-legal-risk
3. This application handles WM_GETOBJECT, and implements an automation interface - https://github.com/UiPathJapan/RespondingWmGetObject 
4. Implementing automation provider (blog post) - https://vivekcek.wordpress.com/2015/01/09/ui-automation-provider-for-a-custom-control-problem-to-solution-approach/
5. List of pattern ID - https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-controlpattern-ids
6. Application which tries to implement several Automation provider sever interfaces - https://github.com/netide/netide. See this, and this.
7. How WM_GETOBJECT works - https://docs.microsoft.com/en-us/windows/win32/winauto/how-wm-getobject-works
8. Tools - https://docs.microsoft.com/en-us/windows/win32/winauto/testing-tools
9. Handling WM_GETOBJECT - https://docs.microsoft.com/en-us/windows/win32/winauto/handling-the-wm-getobject-message
10. Active accessibility vs UI Automation - https://docs.microsoft.com/en-us/windows/win32/winauto/microsoft-active-accessibility-and-ui-automation-compared
11. https://docs.microsoft.com/en-us/windows/apps/develop/accessibility
12. MS Code samples - https://github.com/microsoft/Windows-classic-samples/search?q=accessibility&unscoped_q=accessibility
13. https://docs.microsoft.com/en-us/windows/win32/accessibility/accessibility-whatsnew
14. https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-howto-expose-serverside-uiautomation-provider 
15. Sample win32 custom control that implements IRawElementProviderSimple - https://github.com/microsoft/Windows-classic-samples/tree/main/Samples/UIAutomationSimpleProvider, https://github.com/microsoft/Windows-classic-samples/tree/27ffb0811ca761741502feaefdb591aebf592193/Samples/UIAutomationSimpleProvider 
16. https://www.linkedin.com/pulse/common-approaches-enhancing-programmatic-your-win32-winforms-barker/
17. https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/WinAuto/uiauto-serversideprovider.md
18. "UI Automation Provider Programmer's Guide" - https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/WinAuto/uiauto-providerportal.md
19. Control to patterns mapping - https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-controlpatternmapping