Accessibility is a topic that is often overlooked, as it affects a small percentage of an average product's users. There are, however, numerous benefits to improving an application's accessibility. Easily accessible applications can reach a wider range of users, enhancing the application's inclusivity and reach. Visual ability, something that can change as we age, drives us to accommodate all users. Aside from the ethical side of accessibility, there are also compliance issues on the legal side, as both European and US digital accessibility standards become stricter.
The Uniface lab has been working extensively on improving accessibility for all Uniface desktop applications. The lab has two primary areas of focus: assisting users with compliance with the WCAG 2.0 web standards (as in DSPs) and exposing the desktop applications to screen readers. In this blog, we will focus on the latter. Uniface exposes the UI (User Interface) of generated Windows desktop applications to screen readers and automation tools for many widgets. By exposing the underlying infrastructure, screen readers and automated testing tools can target supported UI elements, and retrieve information regarding their name, value, and status. For these purposes, we’ve used a mixture of two different technologies - UI Automation and MSAA (Microsoft Active Accessibility).
The screen readers use several technologies to recognize Windows controls. They may use UI Automation, MSAA, or other proxy objects to identify the nature of a control and its properties, and they are highly configurable for their users. A framework like Uniface needs to provide all the tools necessary to its developers to expose the underlying UI. It is then the developer's responsibility to make their own application accessible to their users.
So, what does it mean to expose a Windows control? A Windows Control can be a Button, an Edit box, a Radio Button, etc... By exposing it, we make its attributes known to the client tool (screen reader or automation tool). Its purpose, nature, and appearance then become clear to the client tool. The client tool will then choose how to pass on this information to its user. In the next section, you will learn which attributes are used by client tools to accurately describe a control.
Describing Windows Controls
Before delving into best practices, it is good to define a glossary of used terminology. The screen readers can use different frameworks to recognize attributes, but it all boils down to the same control properties.
Name: Also known as AccessibleName, or NameProperty, is probably the most important property of a control. The name should accurately describe the purpose of the control. Let's say there is an Edit box where the developer expects the user to add a last name. The name of the Edit box should be "Last name", "Surname", or something similar.
Role: Also known as AccessibleRole, or ControlType, is a property that defines the nature of the control. It can be a Button, Edit box, Combo Box, Tab, etc...
Value: Also known as AccessibleValue, contains the value of the control. Let's say there is a dropdown list with a list of colors: Green, Red, and Blue, and the user has selected Red. The value of the control should then be "Red".
State: Also known as AccessibleState, it contains information about the status of a control. A control can be active, disabled, checked, selected, focusable, focused, etc...
Help: Help contains the text of the tooltip, if any.
You can read more about descriptive properties in MSDN (1).
Name: Associated Labels and Grid
The most important attribute of screen readers, aside from the value, is the name of the control. Uniface uses the content of the associated label to expose the name of the control. This is in line with Microsoft's guidelines.
For example, an empty Edit box contains no information about what the user is expected to enter. Adding an associated label like "Age" makes the purpose of the control clear to the end user. Developers are expected to have associated labels with their controls, wherever it makes sense. It is possible that a control is self-explanatory and doesn’t need a label; most commonly seen in dropdowns and list boxes.
The Grid is a complicated structure that can be hard to navigate for people with visual difficulties. Uniface has opted to facilitate the traversal of this structure by creating more descriptive names. The name of each cell is comprised of the column name and row number, e.g. "First Name, Row 49".
You can read more about the Name property in MSDN (2).
Role: Control Types in Uniface
The developer never has to worry about the role of the widget, since it's already covered by the Uniface framework. The developer, however, should always be mindful of the limitations of each control, which are documented in detail in the user docs.
Values and States in Uniface
The value of a control takes multiple forms, it can be the index of a selected item in a list, the text inside an Edit box, or even the checked status of a Checkbox. As you probably already guessed, the value is sometimes passed through the state, and the perfect example is the Checkbox. The value is empty, but the screen reader will recognize the status of the control through the state. The developer should never worry about values or states; it's Uniface's responsibility to pass the correct value through various frameworks. It is again important to realize that various screen readers may use different tools that are not compatible with our APIs.
Help and tooltips
This is the cornerstone of our best practices guide. The Name of a control is sometimes not enough for a user to understand what action is expected of them. Sometimes, visual representations are not immediately obvious to users who rely on audio instructions. For example, the Uniface Grid allows the addition of a picture. Screen readers are not able to recognize or describe pictures. It is then up to the developer to add a descriptive tooltip. For every "floppy disk" icon, the developers can add a "Save" tooltip. The purpose of the image is then clear as day to all users. This not only applies to the Grid's picture widget but also to other supported widgets, like Edit boxes and Buttons.
HTML Containers
In Uniface, it's possible to create widgets that contain HTML code. Naturally, those widgets behave similarly to a Chromium-based browser. The developer should be mindful of WCAG 2.0 standards when constructing any kind of web component. It is not up to Uniface to expose any of the developer's code that is related to the HTML container.
Enabling the Accessibility feature
Developers will be glad to know that the Accessibility feature will always be on. The Accessibility feature can also be explicitly specified in the ini file with three different options: “on”, “testmode”, and “off”. There is, however, a caveat. The developer cannot use the automated testing mode (Accessibility=TestMode) setting in tandem with the screen reader accessibility (Accessibility=on). To use a screen reader, the Accessibility setting needs to be "on" or completely removed from the ini file, but never in Testmode. You can read more about this in the following section.
Compatibility with the TestMode feature
“TestMode” is designed for automation tools and will assign technical names to the "Name" property which are machine-friendly, but not human-friendly. Testmode is not affected by our new screen reader feature, and developers should not expect any regression issues with their automated testing.
Troubleshooting
In case developers feel the need to turn our Accessibility feature off for any reason, it's as easy as adding the "Accessibility=off" setting in the UPI section of their ini file.
Performance should never be an issue with Accessibility. The MSAA and UI Automation interfaces are only used when a screen reader or an automation tool asks for information from the Uniface application. Unless one of those tools tries to access Uniface, the Accessibility feature remains asleep.
Conclusions
Developers who find interest in this feature should consult our user docs for best practices, lists of supported widgets, and limitations per widget.
All the above is available in the user docs, under "Accessibility".
References
1: https://learn.microsoft.com/en-us/windows/win32/winauto/content-of-descriptive-properties
2: https://learn.microsoft.com/en-us/windows/win32/winauto/name-property