Accessibility APIs and their modern use case for UX

A staggering 16 percent of the global population, or one in six people, experience significant disability according to the World Health Organization. Even in developed nations, the numbers are high.

In 2019, 394 million people in the WHO European Region had a health condition amenable to rehabilitation services, which includes sensory impairments. This represents two in five people in the region.

In the face of this immense impact, UX professionals should prioritize accessibility in digital products. This ensures we design inclusive experiences that cater to everyone. We’ll discuss how to do so using modern accessibility APIs in this tutorial.

What are accessibility APIs?

Modern accessibility APIs make the task of making digital products accessible quite easy for UX professionals and developers. These APIs have come a long way, and their implementation ensures less grunt work on the part of UX professionals and developers compared to before.

You can represent the user interface in terms of a tree-like structure. For instance, an application would have a menu containing menu items, which would then have child items. Modern accessibility APIs understand each of these items in hierarchical terms to decipher their relationship to each other.

The same logic applies to other elements of the user interface. For instance, a radio button would be understood as belonging to a set of radio buttons in a group. The following is an example of an accessibility tree of a simple web page:

Two common forms of accessibility APIs

There are two main APIs for accessibility — one for the Windows platform and one for the Mac platform. The Windows accessibility API is called the Microsoft UI Automation (UIA), an upgraded replacement for the previous Microsoft Active Accessibility API, or MSAA.

In order to understand Microsoft’s UIA, we have to understand its three main aspects:

• Automation elements: The interface elements that make up the application’s interface, such as input fields and buttons
• Control patterns: The functions of the automation elements, such as being able to click a button for expanding or collapsing
• Properties: The descriptive attributes of the automation elements, such as name, role and current state

Apple’s accessibility API is simply known as the Accessibility API. It’s part of the Cocoa framework for macOS and the UIKit framework for iOS.

Both the Apple Accessibility API and Microsoft’s UIA serve the same purpose: to make the interface elements understandable to assistive technologies. The key difference between Apple’s approach and Microsoft’s is how their APIs are implemented.

Comparing and evaluating Apple’s Accessibility API and Microsoft’s UIA

Apple’s Accessibility API has a more guided approach to allow for a more developer-friendly experience. The API is also deeply integrated with their assistive technologies, such as Voice Over, Switch Control and Live Listen.

This deep integration allows Apple to provide clear guidelines and documentation on how to implement accessibility, including protocols and methods to expose accessibility information. This makes the process of implementing Apple’s Accessibility API fairly straightforward for developers.

In comparison, Microsoft’s UIA requires developers to utilize an extensive set of control patterns and properties. This makes it more complex and requires more manual effort because developers need to create custom automations to expose their interface elements to the accessibility API.

UIA also needs to work across different UI frameworks on Windows devices, which adds to the implementation complexity. However, there is a bright side to this complexity — UIA is designed to work with third-party assistive technologies on Windows.

To understand the difference in complexity, let’s compare the difference in implementation of accessibility for a button:

• Apple’s API only requires the button to have a property called accessibilityLabel defined. There are other properties such as accessibilityValue, accessibilityHint, and accessibilityTraits that are optional on an as-needed basis
• Microsoft’s UIA requires that the button has the properties AutomationId, Name, IsEnabled, ControlType, and Invoke defined

Since Microsoft’s UIA requires more properties defined, you need to have a deep understanding of the boilerplate code. This makes the implementation process more complex to achieve the same result as on Apple’s platform.

Apple’s API handles role and trait mapping automatically based on the nature of the element, whereas Microsoft’s UIA requires more explicit handling of events and controls. Microsoft’s UIA has what’s known as a Provider API to pass on the accessibility information to a Client API for consumption, thus facilitating third-party integrations.

Even though Windows might be the more complex platform, it is better suited for niche use cases where the needs cannot be addressed with readily available assistive technologies. This information will help UX designers make informed decisions on what solutions to implement, knowing the limitations of the two platforms.

Using HTML and ARIA attributes for accessibility

Implementing accessibility on web applications is far easier than implementing on native applications. Both Windows and Mac have assistive technologies integrated with their browsers that use the HTML and ARIA attributes in web applications to make them accessible to all users with disability.

The assistive technologies themselves don’t understand HTML. Behind the scenes, the browser builds an accessibility tree using HTML and CSS to be consumed by the accessibility tools built into the browser:

Therefore, to effectively leverage assistive technologies on browsers, UX designers need to advocate for the proper and meticulous use of proper HTML and ARIA attributes. The process is not complex, but it definitely takes proactive effort to include aspects such as alt text in images and ARIA labels, which are typically not needed by users without disability.

The following image demonstrates the difference between non-semantic and semantic HTML. By simply using semantic HTML, we can ensure that our web application is accessible to assistive technologies in the browser:

Most users are familiar with HTML, so let’s take a closer look at ARIA, which is also HTML but its primary purpose is to make websites more accessible by defining different parts of the website in code using labels.

Taking a closer look at ARIA attributes

As per Webflow, ARIA was initially introduced to address missing attributes in HTML4. However, HTML5 has addressed those gaps, so it’s always advised to use HTML5 instead of ARIA where applicable.

To create a plan for implementing accessibility, we can start by recognizing that there are four main types of disability: visual, physical, auditory and cognitive. We can then plan to solve for accessibility issues based on these four categories.

For visual disabilities:

• Write alt text for images so users with visual disabilities can get an audio description of the image from a screen reader
• Buttons or links should have an aria-label that describes what they do to inform visually impaired users of the action they are about to take
• Ensure the content hierarchy makes sense for screen readers
• Give all objects have an appropriate title, such as titles for iframes

For physical disabilities:

• Ensure users can navigate even in the absence of a keyboard
• Users should not need to use both mouse and keyboard at the same time
• Display focus information in the correct order when users navigate via the keyboard

For auditory disabilities:

• Include descriptive text for audio and video sources
• Include a caption for sounds
• Don’t use interactions that solely rely on sound
• Ensure media players have customizable text size and color options for subtitles

For cognitive disabilities:

• Ensure the navigation system is easy to use
• Ensure that the actions and steps are not too complex or too long

Now, let’s look at the different ARIA attributes to better understand their implementations.

ARIA roles

The role attribute is used to define function, which is used by screen readers to understand their function. For instance, the role can be set to banner, navigation, main, search, and so on. These are fairly self-descriptive, but there are a large number of them to choose from, including ones like alert, article, timer, toolbar, tooltip, tab, and more.

The roles can be categorized into the following.

• Document structure roles: Describe a section of a content
• Landmark roles: Describe large areas of a document
• Widget roles: Describe interactive elements that don’t have HTML tags to define them
• Window roles: For sub-windows within a webpage
• Live region roles: For dynamic content within a webpage

ARIA states and properties

Other than ARIA roles, the other important category of ARIA attributes are states and properties. They define the current condition and characteristics of elements within a page.

For instance, aria-expanded informs screen readers whether a dropdown is collapsed or expanded. Similarly, aria-checked informs screen readers whether a checkbox is checked or not.

The aria-label attribute can be used to describe a button that might not have any text at all. Other examples of ARIA states and properties include:

• aria-active
• aria-current
• aria-disabled
• aria-grabbed
• aria-hidden
• aria-relevant

The examples mentioned above are mostly ARIA state attributes, but there are others for ARIA properties, as well.

While discussing the extensive nature of ARIA attributes, it’s important to mention the need to be cautious about the overuse of ARIA. Overusing ARIA attributes can have the opposite effect of making the webpage more confusing for screen readers. Make sure you conduct exhaustive user testing with real users to ensure the end result is effective and not overwhelming.

Conclusion

Before concluding this article, one last point to keep in mind is that accessibility APIs might struggle to interpret complex user interfaces, or non-standard UI elements.

For such scenarios, aria-label can be an easy solution for web applications, but for native applications with complex patterns, Windows has the properties to address complex changes in UI. Developers will have to be more cautious or consider alternate solutions for the Apple equivalent of the action.

It’s generally agreed upon and understood that designing for accessibility improves brand reputation and trustworthiness. Unfortunately, accessibility efforts are often reactive, tending to arise from avoiding lawsuits. That kind of approach results in delivering the absolute minimum.

Putting in the effort to make the product accessible as part of your core plan makes it more cost effective to implement in the long run. This approach usually also results in a superior end result due to meticulous planning and consideration.

Therefore, UX designers should champion accessibility as both a noble cause and a business decision that leads to better outcomes.